9.5-bob: Monolith vs Microservices — qachon qaysi biri

  MONOLIT — bitta ilova, bitta kodbaza, bitta deploy:
  - Barcha modul (user, order, payment) bir jarayonda
  - Bir DB; modul'lar funksiya chaqiruvi orqali gaplashadi (tarmoq emas)
  - Bir marta deploy (hamma birga)

   MONOLIT "ESKI/YOMON" EMAS — eng keng, eng amaliy:
   Oddiy (bir kod, bir deploy, bir DB)
   Tez (funksiya chaqiruvi — tarmoq latency yo'q)
   Oson debug/test (bir jarayon — stack trace to'liq)
   Tranzaksiya oddiy (bir DB — ACID — 6.9)
   Juda katta bo'lsa — og'ir (build, deploy sekin); butun masshtab

  MIKROSERVIS — ko'p mustaqil xizmat 8.16-bob:
  - Har xizmat: o'z kodbaza, o'z DB, alohida deploy
  - Xizmatlar tarmoq orqali gaplashadi (HTTP/gRPC/queue)

  AFZALLIK:
   Mustaqil masshtab (faqat og'ir qism)
   Mustaqil deploy (jamoa parallel ishlaydi)
   Texnologiya erkinligi; xato izolyatsiyasi

   HAQIQIY NARX (ko'pincha yashiriladi):
   Tarmoq (latency, ishonchsizlik — xizmat o'rtasida)
   Taqsimlangan tranzaksiya (Saga — 8.16: 2.10 — murakkab)
   Monitoring/tracing (qaysi xizmatda muammo?)
   Deploy/infra (Kubernetes, service mesh — 10)
   Ma'lumot izchilligi (eventual consistency)
   Lokal ishlab chiqish qiyin (10 xizmat lokal?)

  ┌──────────────────┬─────────────────────┬─────────────────────┐
  │                  │ MONOLIT             │ MIKROSERVIS         │
  ├──────────────────┼─────────────────────┼─────────────────────┤
  │ Murakkablik      │ Kod (bitta katta)   │ Tizim (ko'p+tarmoq) │
  │ Deploy           │ Bir marta (hammasi) │ Mustaqil (har xizmat)│
  │ Masshtab         │ Butun (gorizontal)  │ Tanlab (faqat og'ir) │
  │ Tranzaksiya      │ Oddiy (ACID)        │ Murakkab (Saga)     │
  │ Tarmoq           │ Yo'q (funksiya)     │ Bor (latency)       │
  │ Debug            │ Oson (bir joy)      │ Qiyin (tracing)     │
  │ Jamoa            │ Kichik-o'rta        │ Katta (parallel)    │
  │ Lokal dev        │ Oson                │ Qiyin (ko'p xizmat) │
  │ Boshlang'ich tez │ Tez                 │ Sekin (infra)       │
  └──────────────────┴─────────────────────┴─────────────────────┘
   Monolit: murakkablik KODDA; Mikroservis: murakkablik TIZIMDA

  MODULAR MONOLITH — monolit + mikroservis afzalligi (eng yaxshi balans):
  - Bitta deploy (monolit — oddiy)
  - Lekin ICHIDA qat'iy modullar (mikroservis — chegaralar)
  - Har modul: o'z chegarasi, interfeysi (9.4 bounded context)
  - Modullar interfeys orqali gaplashadi (to'g'ridan ichkariga emas)

  ┌─────────────────────────────────────┐
  │         MODULAR MONOLITH            │
  │  ┌────────┐ ┌────────┐ ┌────────┐  │
  │  │ Users  │ │ Orders │ │Payment │  │  qat'iy modullar
  │  │ (modul)│ │ (modul)│ │ (modul)│  │   (interfeys orqali)
  │  └────────┘ └────────┘ └────────┘  │
  │         BITTA DEPLOY                 │
  └─────────────────────────────────────┘

   Oddiy deploy + toza chegaralar (kerak bo'lsa — oson ajratish)

  CONWAY QONUNI (1967):
  "Tizim dizayni tashkilot aloqa tuzilmasini aks ettiradi"

   Kodning arxitekturasi JAMOA tuzilmasini takrorlaydi:
  - 1 jamoa  monolit (tabiiy)
  - 5 mustaqil jamoa  5 xizmat (tabiiy)
  - 3 jamoa, lekin 10 xizmat  kaos (jamoaxizmat mos emas)

   TESKARI manyovr (Inverse Conway):
  Avval JAMOANI tuz (qanday arxitektura xohlasang),
  keyin arxitektura tabiiy shakllanadi

   Arxitektura = jamoa tuzilmasi (alohida emas)

  MONOLIT (modular) — DEFAULT, agar:
   Jamoa kichik-o'rta (< 15-30 dasturchi)
   Yangi loyiha / startup (domen hali aniq emas)
   MVP, tez bozorga chiqish kerak
   Yuk o'rtacha (< 1M so'rov/kun)
   Tranzaksiya muhim (moliyaviy — ACID)
   Kichik DevOps jamoasi (infra murakkabligini ko'tara olmaydi)

   Shubha bo'lsa — MODULAR MONOLITH (xato bo'lsa, arzon tuzatish)

  MIKROSERVIS — faqat HAQIQIY signal bo'lsa:
   Katta jamoa (> 30-50 dasturchi — parallel ishlash kerak)
   Mustaqil masshtab ISBOTLANGAN (bir qism 10x yuklangan)
   Mustaqil deploy zarur (jamoalar bir-birini kutmasligi)
   Turli texnologiya zarur (ML — Python, real-time — Go)
   Domen ANIQ (bounded context aniqlangan — 9.4)
   Kuchli DevOps (Kubernetes, monitoring, CI/CD — 10)

   NOTO'G'RI sabablar (mikroservisga emas):
  - "Zamonaviy/moda" (texnik sabab emas)
  - "Google shunday qiladi" (siz Google emassiz — masshtab boshqa)
  - "Kelajakda kerak bo'lar" (YAGNI — 9.1: 2.12)

   DISTRIBUTED MONOLITH — eng yomon kombinatsiya:
  Mikroservis ko'rinishi (ko'p xizmat) + monolit bog'liqligi (qattiq)

  Belgilari:
  - Xizmatlar bir-birisiz ishlay olmaydi (qattiq bog'liq)
  - Bir o'zgarish  ko'p xizmatni birga deploy
  - Bir xizmat yiqilsa  hammasi yiqiladi
  - Umumiy DB (xizmatlar bir DB'ga tegadi)

   Mikroservis NARXI + monolit CHEKLOVI (ikkisining yomoni!)
   Sabab: noto'g'ri ajratish (chegara yo'q — 9.4, Conway 2.5)

  MONOLIT'DAN AJRATISH SIGNALLARI (haqiqiy ehtiyoj):
  1. Build/deploy juda sekin (har kichik o'zgarish — 30 daqiqa build)
  2. Jamoalar bir-birini bloklaydi (deploy navbati)
  3. Bir modul boshqalardan butunlay boshqa masshtab (10x yuk)
  4. Bir modul boshqa texnologiya talab qiladi (ML, real-time)
  5. Bir modul tez-tez yiqiladi (boshqalarni ham yiqitadi)

   Bu signallar PAYDO BO'LGANDA ajrat (oldindan emas)
   Eng og'ir/mustaqil modulni BIRINCHI ajrat (eng ko'p foyda)

  STRANGLER FIG — monolit'ni asta-sekin ajratish (xavfsiz):
  (nomi: anjir daraxti daraxtni asta-sekin o'rab, o'rnini egallaydi)

  1. Yangi imkoniyatni alohida xizmat sifatida qur (monolit'ga emas)
  2. Mavjud modulni asta-sekin chiqar (bittadan)
  3. Proxy/Gateway eski va yangini yo'naltiradi (8.16: API Gateway)
  4. Modul ko'chgach — monolit'dan o'chir
  5. 12-18 oy davomida (big bang emas!)

   "Big bang rewrite" (hammasini birdan qayta yozish) — FALOKAT
   Strangler Fig: biznes ishlashda davom etadi (xavf kam)

  MIKROSERVISDA XIZMATLAR QANDAY GAPLASHADI:

  SINXRON (so'rov-javob — kutadi):
  - REST/gRPC (8.16: 2.5) — xizmat A  B  javob kutadi
   Oddiy, darrov javob;  bog'liqlik (B yiqilsa A ham), latency zanjiri

  ASINXRON (event/message — kutmaydi):
  - Message queue (RabbitMQ/Kafka — 8.16: 2.6) — A event chiqaradi
   Bo'shashgan bog'lanish, chidamli (B yiqilsa, event navbatda)
   Eventual consistency, murakkab kuzatuv

   Iloji bo'lsa ASINXRON (bog'liqlik kam — 9.7 event-driven)

  MONOLIT: bir DB  ACID tranzaksiya (oddiy — 6.9)
  BEGIN  order yarat + zaxira kamaytir + to'lov  COMMIT (atomik)

  MIKROSERVIS: har xizmat o'z DB  tranzaksiya TAQSIMLANGAN (qiyin)
  - ACID ishlamaydi (DB'lar alohida)
  - SAGA (8.16: 2.10): qadamlar + kompensatsiya (orqaga)
  - Eventual consistency (darrov emas — biroz keyin izchil)

   Bu — mikroservisning ENG QIYIN qismi (monolitda yo'q muammo)
   Tranzaksiya muhim (moliyaviy)  monolit afzal

   MIKROSERVIS QOIDASI: har xizmat — O'Z DB'si (database-per-service)
  - Order xizmat  order_db;  Payment xizmat  payment_db
  - Boshqa xizmat DB'siga TO'G'RIDAN so'rov YO'Q (faqat xizmat API orqali)

   SHARED DATABASE (bir DB'ni ko'p xizmat bo'lishadi) — ANTI-PATTERN:
  - Bir jadval sxemasi o'zgarsa  ko'p xizmat sinadi (yashirin bog'liqlik)
  - Xizmatlar mustaqil deploy qila olmaydi (DB — umumiy tugun)
  - Bu — distributed monolith'ga to'g'ri yo'l 2.8-bob

   To'g'ri: har xizmat o'z DB'si (mustaqillik — chegara aniq)
   Narx: ma'lumot bo'linadi  JOIN yo'q  API composition / eventual

  SAGA — taqsimlangan tranzaksiya (ketma-ket qadamlar + kompensatsiya):

  1) CHOREOGRAPHY (xoreografiya — markazsiz, event bilan):
     Order  "order.created" event  Payment tinglaydi  "payment.done"
      Inventory tinglaydi  ... (har xizmat keyingisini bilmaydi)
      Bo'shashgan, markazsiz;   oqimni kuzatish qiyin (kim keyingi?)

  2) ORCHESTRATION (orkestratsiya — markaziy koordinator):
     Saga Orchestrator  Order chaqir  Payment chaqir  Inventory chaqir
     Xato bo'lsa  teskari tartibda kompensatsiya (bekor qil)
      Oqim aniq, bir joyda;   koordinator — markaziy nuqta

   2PC (Two-Phase Commit — klassik taqsimlangan tranzaksiya) NEGA YOMON:
  - Barcha xizmat "prepare"  keyin "commit" (ikki bosqich)
  - Koordinator kutganda — hamma LOCK ushlaydi (bloklanish)
  - Bir xizmat yiqilsa  hamma osilib qoladi (kam mavjudlik)
  - Masshtablanmaydi, sekin  mikroservisda ISHLATILMAYDI
   Shuning uchun Saga (eventual) tanlanadi, 2PC emas

  MONOLIT masshtab (gorizontal):
  - Butun ilovani ko'paytirish (load balancer ortida N nusxa — 10)
  -  Oddiy;  butun (kichik qism og'ir bo'lsa ham hammasi ko'payadi)

  MIKROSERVIS masshtab (tanlab):
  - Faqat og'ir xizmatni ko'paytirish (boshqalari kam)
  -  Samarali (resurs);  murakkab (orkestratsiya — Kubernetes 10)

   Monolit ham yaxshi masshtablanadi (ko'p loyiha uchun yetadi)
   "Mikroservis kerak, chunki masshtab" — ko'pincha noto'g'ri
  (monolit + load balancer + cache + DB optimizatsiya yetadi)

  MONOLIT: bir jarayon  bitta stack trace (xato qayerda — darrov ko'rinadi)

  MIKROSERVIS: bir so'rov 5 xizmatdan o'tadi  xato QAYSI xizmatda?
  ┌──────────────────────────────────────────────────────────┐
  │ Gateway  Order  Payment  Inventory  Notification     │
  │  (har biri alohida log — bir-biriga bog'lanmagan)         │
  └──────────────────────────────────────────────────────────┘

  YECHIM 1 — CORRELATION ID (so'rov identifikatori):
  - Gateway bir X-Request-Id yaratadi (masalan: abc-123)
  - Bu ID har xizmatga UZATILADI (header'da) va har log'ga yoziladi
  - Muammo bo'lsa  abc-123 bo'yicha BARCHA xizmat logini yig'ish

  YECHIM 2 — DISTRIBUTED TRACING (OpenTelemetry / Jaeger — 10):
  - Har qadam "span" (kim, qancha vaqt)  bir "trace"ga birlashadi
  - Butun yo'lni vizual ko'rish: qaysi xizmat sekin, qaysi xato

   Mikroservisda kuzatuvchanlik OPSIYA emas — MAJBURIY (aks holda ko'r)

  QAROR DARAXTI (qaysi arxitektura):

  Jamoa < 15-30 dasturchi?
  └─ HA  MODULAR MONOLITH (deyarli har doim)

  Jamoa katta + domen aniq + masshtab isbotlangan + kuchli DevOps?
  ├─ HAMMASI HA  Mikroservis (yoki qisman)
  └─ Biror YO'Q  Modular monolith (kerakli qismni keyin ajrat)

   DEFAULT: Modular Monolith
   Mikroservis: kuchli, ISBOTLANGAN sabab bo'lganda
   Hybrid: monolit + bir-ikki ajratilgan xizmat (eng amaliy katta tizim)

  REAL TAJRIBA (2026):
  - Amazon Prime Video: mikroservis  monolit (90% xarajat tejash)
  - Segment: mikroservis  monolit (murakkablik boshqarib bo'lmadi)
  - Shopify: ulkan modular monolith (muvaffaqiyatli)
  - GitHub, Stack Overflow: monolit (ulkan masshtab)
  - Netflix, Uber: mikroservis (haqiqatan katta — minglab dasturchi)

   Xulosa: mikroservis FAQAT haqiqatan katta tashkilotga (Netflix)
   Ko'pchilik uchun modular monolith (Shopify) to'g'ri tanlov

   DEFAULT — modular monolith (toza modul/chegara — 2.4, 9.4)
   "Monolith first" (kerak bo'lganda ajrat — 2.6, 2.9)
   Conway: jamoa = arxitektura 2.5-bob
   Mikroservis — isbotlangan signal (jamoa/masshtab — 2.7)
   Distributed monolith'dan QOCH (chegara — 2.8, 9.4)
   Strangler Fig (asta-sekin — big bang emas — 2.10)
   Asinxron aloqa (bog'liqlik kam — 2.11, 9.7)
   Tranzaksiya muhim  monolit 2.12-bob
   Database-per-service (shared DB — anti-pattern — 2.12.1)
   Saga (2PC emas); eventual consistency (2.12.2)
   Avval monolit masshtabini sina 2.13-bob
   Kuzatuvchanlik majburiy — correlation ID, tracing (2.13.1)
   Nano/chatty anti-naqshlaridan qoch 2.8-bob
   Hybrid (monolit + og'ir xizmat — amaliy — 2.14)

QAROR 2.14-bob:
Jamoa < 30  Modular Monolith (default)
Katta + domen aniq + masshtab isbotlangan + DevOps  Mikroservis
Aks holda  Modular Monolith (keyin ajrat)

NAQSHLAR:
Modular Monolith — bir deploy + qat'iy modul (NestJS modul — 8.1)
Strangler Fig — asta-sekin ajratish (12-18 oy — 2.10)
Hybrid — monolit + og'ir xizmat 2.14-bob

QOCH: Distributed Monolith 2.8-bob, Big Bang rewrite 2.10-bob, erta mikroservis

  Modular monolith — NestJS modul'lari 8.1-bob qat'iy chegara bilan:
  src/
  ├── modules/
  │   ├── users/               USER moduli (chegara)
  │   │   ├── users.module.ts
  │   │   ├── users.service.ts
  │   │   └── users.public-api.ts    FAQAT shu interfeys tashqariga
  │   ├── orders/              ORDER moduli
  │   │   ├── orders.service.ts
  │   │   └── orders.public-api.ts
  │   └── payments/            PAYMENT moduli
  ├── shared/                  umumiy (DTO, util)
  └── app.module.ts            bir deploy

   Modul faqat boshqa modulning PUBLIC-API'sini ishlatadi
   Modul ichki service'ga to'g'ridan tegmaydi (chegara — 9.4)

// users/users.public-api.ts — FAQAT shu tashqariga ochiq (chegara)
@Injectable()
export class UsersPublicApi {
  constructor(private usersService: UsersService) {}   // ichki service (yashirin)

  // Boshqa modullar FAQAT shu metodlarni ko'radi (interfeys — SOLID 9.1)
  async userBor(id: string): Promise<boolean> {
    return this.usersService.mavjudmi(id);
  }
  async userMa'lumot(id: string): Promise<UserPublicDto> {
    const u = await this.usersService.bitta(id);
    return { id: u.id, ism: u.ism };                   // faqat public maydonlar
  }
}

// orders/orders.service.ts — users modulini FAQAT public-api orqali
@Injectable()
export class OrdersService {
  constructor(private usersApi: UsersPublicApi) {}     // public API (ichki emas!)
  async yarat(userId: string, dto: any) {
    if (!(await this.usersApi.userBor(userId))) {       // chegara orqali
      throw new BadRequestException("User topilmadi");
    }
    // ...
  }
}
//  OrdersService UsersService'ga TO'G'RIDAN tegmaydi (chegara — kerak bo'lsa oson ajratish)

// .eslintrc — modul chegarasini buzishni bloklash (import cheklash)
{
  "rules": {
    "no-restricted-imports": ["error", {
      "patterns": [
        {
          "group": ["**/users/!(users.public-api)*"],   // users ichki — taqiq
          "message": "Boshqa modul users.public-api orqali ishlatilsin (chegara)"
        }
      ]
    }]
  }
}
//  Dasturchi chegarani buzsa — lint xato (avtomatik himoya — distributed monolith oldini olish)

// Modullar event orqali gaplashadi (to'g'ridan emas — bo'shashgan — 9.7)
// Buyurtma yaratilganda — payment, notification modullari reaksiya (bir-birini bilmaydi)
@Injectable()
export class OrdersService {
  constructor(private eventEmitter: EventEmitter2) {}   // NestJS event (8.16)

  async yarat(dto: any) {
    const order = await this.repo.save(dto);
    this.eventEmitter.emit("order.created", { orderId: order.id });   // event (bo'shashgan)
    return order;
  }
}

// notification moduli tinglaydi (orders'ni bilmaydi)
@OnEvent("order.created")
async buyurtmaBildirishnoma(payload: { orderId: string }) {
  await this.notify.yubor(payload.orderId);
}
//  Event bilan — modullar mustaqil (kerak bo'lsa, modul  mikroservis OSON: event  message queue)

// Bosqich 1: notification modulini ajratish (eng mustaqil)
// Monolit ichida event'ni endi message queue'ga uzatish (8.16)
@OnEvent("order.created")
async forwardToQueue(payload: any) {
  // Eski: monolit ichida ishladi
  // Yangi: message queue'ga (alohida notification xizmati oladi — 8.16: 2.6)
  await this.queue.emit("order.created", payload);     // mikroservisga ko'prik
}

// Bosqich 2: alohida notification mikroservisi (8.16)
@EventPattern("order.created")
async buyurtmaBildirishnoma(@Payload() payload: any) {
  await this.notify.yubor(payload.orderId);            // endi alohida xizmatda
}
//  Modul EVENT bilan ishlagani uchun — ajratish OSON (interfeys o'zgarmadi)
//  Modular monolith (event)  mikroservis (message queue) — silliq o'tish

  HYBRID — eng amaliy katta tizim (monolit + og'ir xizmatlar):

  ┌──────────────────────────────┐
  │   MODULAR MONOLITH (asosiy)  │   user, order, product, payment
  │   (biznes mantiqning 90%)    │     (tranzaksiya, oddiy — 2.12)
  └──────────┬───────────────────┘
             │ event/message queue 8.16-bob
     ┌───────┼───────┐
     ▼       ▼       ▼
  Video   ML/AI   Notification    FAQAT og'ir/maxsus ajratilgan
  (Go)    (Python)  (masshtab)      (haqiqiy sabab — 2.7)

   Asosiy biznes monolitda (oddiy); faqat maxsus qism ajratilgan
   Netflix emas — pragmatik (real loyihalar shunday)

// MONOLIT — oddiy ACID tranzaksiya (bir DB — 6.9, 8.13)
async buyurtmaYarat(dto: any) {
  return this.dataSource.transaction(async (manager) => {   // ATOMIK
    const order = await manager.save(Order, dto);
    await manager.decrement(Product, { id: dto.productId }, "zaxira", dto.miqdor);
    await manager.save(Payment, { orderId: order.id, summa: dto.summa });
    return order;                                       // hammasi yoki hech narsa (ACID)
  });
}

// MIKROSERVIS — Saga (taqsimlangan — murakkab — 8.16: 2.10)
async buyurtmaYaratSaga(dto: any) {
  const order = await this.orderService.yarat(dto);     // 1-xizmat
  try {
    await this.inventoryService.kamaytir(dto);          // 2-xizmat (tarmoq)
    await this.paymentService.tolov(dto);               // 3-xizmat (tarmoq)
  } catch (e) {
    await this.orderService.bekor(order.id);            // KOMPENSATSIYA (orqaga)
    throw e;
  }
}
//  Monolit: 5 qator, ishonchli (ACID). Mikroservis: murakkab, eventual.

  MONOLIT masshtab — ko'p loyiha uchun yetadi:

  ┌─────────────┐
  │Load Balancer│ (Nginx — 10)
  └──────┬──────┘
    ┌────┼────┐
    ▼    ▼    ▼
  App   App  App     monolit N nusxa (gorizontal — bir xil)
    └────┼────┘
         ▼
   ┌──────────┐  ┌───────┐
   │  DB      │  │ Redis │   shared DB + cache 8.15-bob
   │ (replica)│  │(cache)│
   └──────────┘  └───────┘

  + DB read replica 6.15-bob + Redis cache 8.15-bob + CDN
   Bu odatda 1M+ so'rov/kun ko'taradi (mikroservissiz)

//  DISTRIBUTED MONOLITH (eng yomon — qochish)
// Xizmat A xizmat B'ga SINXRON, zanjir bilan bog'liq:
async buyurtma(dto: any) {
  const user = await this.http.get(`http://user-service/users/${dto.userId}`);   // B kutadi
  const product = await this.http.get(`http://product-service/${dto.productId}`); // C kutadi
  const stock = await this.http.get(`http://inventory/${dto.productId}`);         // D kutadi
  //  B/C/D dan bittasi yiqilsa/sekinlasa  A ishlamaydi (qattiq bog'liq!)
  //  Umumiy DB bo'lsa — yana yomon
}

//  To'g'ri: modular monolith (funksiya chaqiruvi — tarmoq yo'q)
async buyurtmaToori(dto: any) {
  const user = await this.usersApi.userBor(dto.userId);       // funksiya (tez, ishonchli)
  // bir jarayon — tarmoq xatosi yo'q, ACID tranzaksiya mumkin (2.12)
}

  ARXITEKTURA QARORI — checklist (loyiha uchun):

  □ Jamoa hajmi? (< 15-30  monolit)
  □ Domen aniqmi? (yo'q  monolit, keyin aniqlanadi — 9.4)
  □ Masshtab ISBOTLANGANmi? (taxmin  monolit; real 10x  ajrat)
  □ Tranzaksiya muhimmi? (ha  monolit — ACID)
  □ DevOps kuchimi? (zaif  monolit; Kubernetes bor  mikroservis mumkin)
  □ Mustaqil deploy zarurmi? (jamoalar bloklayaptimi?)
  □ Turli texnologiya kerakmi? (ML/real-time  maxsus xizmat)

  Ko'p "monolit" javob  Modular Monolith
  Ko'p "mikroservis" javob + ISBOTLANGAN  Mikroservis (yoki hybrid)

   Shubhada — MODULAR MONOLITH (xato arzon tuzatiladi)

 3 dasturchi  10 mikroservis (boshqarib bo'lmaydi — 2.7)
 modular monolith (keyin kerak bo'lsa ajrat)

 "zamonaviy/Google shunday" (texnik sabab emas — 2.7)
 isbotlangan signal (jamoa/masshtab)

 ko'p xizmat + qattiq bog'liq + umumiy DB (2.8)
 modular monolith yoki to'g'ri ajratilgan mikroservis

 monolitni birdan qayta yozish (falokat — 2.10)
 Strangler Fig (asta-sekin)

 monolitdan qochish (noto'g'ri tushuncha — 2.1)
 modular monolith — kuchli, amaliy tanlov