Монолит

Одно приложение как единое целое

В монолите основные части продукта находятся в одном приложении и обычно проходят общий жизненный цикл: собираются, тестируются и развёртываются вместе. Внутри могут быть контроллеры, бизнес-логика, работа с данными и десятки функциональных областей, но снаружи это один запускаемый компонент.

Client -> Monolith -> Database
          |-- users
          |-- orders
          |-- payments

Это не означает, что код обязательно смешан в одну кучу. Монолит вполне может иметь аккуратные пакеты, модули и зависимости. Его определяет прежде всего единая граница развёртывания, а не отсутствие структуры внутри.

Почему монолит удобен на старте

Один процесс проще запускать локально, тестировать и наблюдать. Вызовы между частями приложения обычные локальные вызовы, а изменения данных часто можно выполнить в одной транзакции. Команде не нужно сразу решать вопросы сетевых сбоев, межсервисной совместимости и координации нескольких развёртываний.

Пока продукт и команда не стали слишком большими, такая простота часто важнее независимого масштабирования каждой функции. Изменение, которое затрагивает несколько частей системы, можно реализовать и выпустить одним согласованным обновлением.

Где начинают появляться ограничения

По мере роста приложения общая граница развёртывания становится теснее. Маленькое изменение требует пересобрать и выпустить весь продукт, разные команды чаще затрагивают один и тот же код, а масштабировать приходится весь процесс даже тогда, когда нагрузка растёт только на одну функцию.