Модульний моноліт чи мікросервіси для вебзастосунків

Коротка відповідь

Модульний моноліт доречний для однієї команди зі спільним випуском. Microservices — для незалежних обов’язків, deployment, scale чи fault-isolation за здатності підтримувати distributed-контракти. Моноліт не означає заплутаний код, microservice — не просто маленька папка з HTTP.

Практичні кроки реалізації

1. Визначте модулі за обов’язками

Групуйте правила спільних змін, як booking чи invoice. Модуль має явний interface і приватні деталі. Викликайте бізнес-операцію, не змінюйте чужі таблиці. Так межа існує до мережевих відмов, retries й versioning.

2. Позначте інваріанти й транзакції

Одна database-транзакція захищає пов’язані updates моноліту. Незалежні бази потребують іншої координації чи компенсації. Визначте негайну узгодженість і eventual. Не діліть тісний write лише за схемою: координація може ускладнити межу.

3. Доведіть потребу незалежності

Назвіть блоковану capability, owner і workload. Додайте contracts, service-auth, deployment, tracing, on-call і recovery у вартість. Service зі спільними таблицями й lockstep-випуском не незалежний. Почніть із межі, здатної витримати distributed-failure.

Приклад реалізації

Interface описує booking усередині моноліту без transport. Після extraction результати допомагають HTTP чи message-контракту, але потрібні serialization, timeout, auth і versioning. Межа полегшує extraction, не робить безкоштовним.

type ReservationResult =
  | { kind: "accepted"; reservationId: string }
  | { kind: "unavailable" }
  | { kind: "denied" };

export interface Reservations {
  reserve(input: {
    verifiedCustomerId: string;
    slotId: string;
    requestId: string;
  }): Promise<ReservationResult>;
}

Компроміси та альтернативи

Моноліт ділить runtime і release та зменшує network-координацію. Microservices ізолюють workload, але додають partial-failure, tooling і compatibility. Окремий worker для довгих jobs — проміжний варіант. Топологія має відповідати виміряній потребі.

Поширені помилки

Не плутайте modules і services, не діліть writable-schema між незалежними owners і не створюйте довгі synchronous-chain. Retry посилює overload, event не гарантує exactly-once. Один deployment також потребує меж імпортів і writes.

Перевірка перед випуском

• ☐ Modules мають interfaces і owners.
• ☐ Інваріанти мають consistency-вимоги.
• ☐ Service-split вирішує конкретну проблему.
• ☐ Failures і compatibility описані.
• ☐ Оператори простежують і відновлюють workflow.

Поширені запитання

Чи моноліт не підходить зростанню?

Ні. Модулі, ресурси й дані підтримують зростання. Виносьте за конкретної потреби.

Чи services можуть ділити базу?

Можуть, але shared-write поєднує правила й deployment. Фіксуйте зв’язок, не обіцяйте непідтверджену ізоляцію.

Наступний крок

Створіть ясну межу й виміряйте проблему extraction з операційними витратами. Залиште in-process до користі незалежної роботи.

Первинні джерела

• Microsoft: архітектура microservices
• PostgreSQL: транзакції

Пов’язані матеріали та приклади

• Архітектура вебсайтів
• Як вибрати технологічний стек для вебсайту
• Статика, SSR чи CSR: вибір моделі рендерингу
• Next.js чи React із Vite для нового вебсайту
• Публічний каталог проєктів