У яких випадках ви б обрали моноліт, а в яких — мікросервіси?

Повне пояснення

Що це і навіщо

• Моноліт – одне виконуване застосування, що містить усі бізнес‑логіку й залежності. Підходить для швидкого MVP, невеликих команд і простих сценаріїв.
• Мікросервіси – набір незалежних сервісів, кожен із власним життєвим циклом і базою даних. Підходять, коли потрібна масштабованість, розподілена команда і гнучке оновлення.

Ключові принципи

• Складність: моноліт простіший у розгортанні, але складніше масштабувати. Мікросервіси потребують CI/CD, оркестрації (K8s) і мережевих патернів.
• Тестування: у моноліті можна запускати інтеграційні тести всього застосунку; у мікросервісах потрібні контракт‑тести і end‑to‑end.
• Безпека: моноліт має одну точку входу, а мікросервіси вимагають окремих токенів і політик.

Як це працює

• У моноліті всі модулі компілюються в один бінарний файл. Зміни в одному компоненті потребують повного перезапуску.
• У мікросервісах кожен сервіс розгортається окремо, спілкується через HTTP/REST або gRPC. Зміни в одному сервісі не впливають на інші.

Практика і реалізація

• Моноліт: NestJS, Express або Fastify з однією базою даних.
• Мікросервіси: NestJS‑microservices, Docker Compose або Kubernetes. Кожен сервіс має власний Dockerfile.

Тестування

• Моноліт: Jest + Supertest для всього API.
• Мікросервіси: Contract‑тести (Pact), integration tests з Docker‑Compose, end‑to‑end через Playwright.

Безпека

• Моноліт: один JWT‑сервер, централізована авторизація.
• Мікросервіси: кожен сервіс має власний auth‑gateway, використання OAuth2 / OpenID Connect.

Особливості в контексті backend (NestJS, Express, Node.js)

• Моноліт легше налаштувати в NestJS: один модуль AppModule.
• Мікросервіси у NestJS реалізуються через MicroserviceModule і Transporter (TCP, Redis, NATS).

Оптимізація та edge cases

• Моноліт: проблеми з пам’яттю, довгий час збірки.
• Мікросервіси: мережеві затримки, складність транзакцій.

Часті помилки

1. Перенавантаження монолітів через великі залежності.
2. Неправильна конфігурація Docker‑Compose для мікросервісів.
3. Відсутність централізованого логування у мікросервісах.
4. Синхронізація схеми бази даних у мікросервісах.
5. Перевантаження мережі через надмірну кількість HTTP‑запитів.
6. Неправильне використання shared libraries між мікросервісами.
7. Відсутність fallback‑логіки у випадку падіння сервісу.
8. Недостатня моніторингова інфраструктура (Prometheus, Grafana).

Cheatsheet

• Моноліт: швидка розробка, простий деплой.
• Мікросервіси: масштабованість, незалежність, складна інфраструктура.

Follow‑up питання

1. Як впровадити CI/CD для мікросервісної архітектури?
2. Які патерни забезпечують консистентність даних між мікросервісами?
3. Як обрати транспортний протокол у NestJS‑microservices?