Микросервисы — ключевые шаблоны проектирования
(описание к предыдующему посту)

Всегда начинайте с монолита. По мере роста вашего приложения и появления узких мест в отдельных компонентах (или когда им требуется независимое масштабирование) постепенно выделяйте их в микросервисы.

Netflix стал первопроходцем в применении архитектуры микросервисов, разбив своё монолитное приложение на сотни небольших сервисов.

Это позволило компании быстро масштабироваться и добиться высокой доступности.

Если вы переходите на архитектуру микросервисов, обратите внимание на следующие шаблоны:

[1.] Шаблон API‑шлюз (API Gateway)
◾️ единая точка входа для клиентов;
◾️ обработка маршрутизации;
◾️ аутентификация;
◾️ решение прочих сквозных задач.

[2.] Шаблон Прерыватель цепи (Circuit Breaker)
◾️ предотвращает каскадные сбои за счёт изоляции неисправных сервисов.

[3.] Шаблон Агрегатор (Aggregator)
◾️ объединяет данные из нескольких сервисов в единый ответ.

[4.] Шаблон Цепочка (цепочка ответственности) (Chained (Chain of Responsibility))
◾️ упорядочивает обработку запросов через последовательность сервисов.

[5.] База данных для каждого сервиса (Database per Service)
◾️ каждый сервис имеет собственную приватную базу данных для слабой связности.

[6.] Шаблон Saga
◾️ управляет распределёнными транзакциями между сервисами с помощью серии локальных транзакций.

[7.] Шаблон Сайдкар (Sidecar)
◾️ расширяет функциональность сервиса за счёт отдельного компонента, развёрнутого рядом.

[8.] Бэкенды для фронтендов (BFF / Backends for Frontends)
◾️ создаёт специализированные бэкенд‑сервисы для конкретных фронтендов.

[9.] CQRS (Command Query Responsibility Segregation - разделение ответственности за команды и запросы)
◾️ разделяет операции чтения и записи для улучшения масштабируемости и производительности.

[10.] Шаблон Event Sourcing
◾️ фиксирует все изменения состояния приложения в виде последовательности событий.

[11.] Асинхронный обмен сообщениями
◾️ обеспечивает слабую связность между сервисами с помощью очередей сообщений или брокеров.

[12.] Шаблон Strangler Fig
◾️ поэтапно переносит монолитное приложение на микросервисы.

[13.] Внешняя конфигурация
◾️ хранит настройки конфигурации вне кода приложения.

[14.] Централизованное логирование и мониторинг
◾️ агрегирует журналы и метрики из всех микросервисов для наблюдаемости.

[15.] Шаблон Обнаружение сервисов (Service Discovery)
◾️ позволяет сервисам динамически находить друг друга.

[16.] Шаблон Anti-Corruption Layer
◾️ создаёт слой изоляции, чтобы защитить ваше приложение от негативного влияния изменений во внешних системах.

[17.] Шаблоны декомпозиции
◾️ стратегии разбиения монолитного приложения на микросервисы:

1. Декомпозиция по бизнес‑возможностям → привязка сервисов к отдельным бизнес‑функциям (например, обработка заказов, управление запасами).
2. Декомпозиция по поддоменам → дальнейшее разделение возможностей на более мелкие и сфокусированные сервисы (например, управление клиентами в рамках заказов).

«Золотая середина» между монолитной и микросервисной архитектурами — модульный монолит.