Монолит и модульный монолит
Тема дорожной карты · Backend разработчик
Монолитная архитектура — шаблон проектирования программного обеспечения, при котором все компоненты приложения — маршрутизация HTTP, бизнес-логика, доступ к данным и фоновые задания — собираются и разворачиваются как единое целое; для большинства бэкенд-проектов это практичная и нередко оптимальная отправная точка. Хорошо структурированный монолит, построенный на таких фреймворках, как Spring Boot, Django, Ruby on Rails или NestJS, способен обслуживать миллионы запросов в день при горизонтальном масштабировании за балансировщиком нагрузки и грамотной оптимизации запросов к PostgreSQL или MySQL. Главный риск монолитной архитектуры состоит в том, что по мере роста кодовой базы модули становятся тесно связанными, что прогрессивно усложняет независимые деплои, точечное масштабирование и обновление технологий — эта проблема смягчается соблюдением строгих модульных границ и применением паттерна Strangler Fig для постепенного выделения микросервисов. Развёртывание монолита с Docker и Kubernetes не представляет сложности: единый Dockerfile собирает образ, а манифест Kubernetes Deployment с горизонтальным автомасштабированием подов справляется со всплесками трафика. Понимание монолитной архитектуры необходимо каждому бэкенд-разработчику, поскольку большинство реальных систем начинается именно с монолита, и умение определить момент — и способ — перехода к микросервисам или модульному монолиту является критически важным инженерным решением.
Как это работает
Монолит и модульный монолит имеет варианты: монолит (один деплоябл, простой ops, тяжело масштабировать команды за ~30 инженеров), modular monolith (один деплоябл, внутренние границы модулей, масштабируется намного дальше, чем считают), микросервисы (много мелких сервисов, сложный ops, масштабирует команды). Паттерны: hexagonal / clean architecture (отделить домен от инфры), CQRS (раздельные read + write модели), event sourcing (state из event log), domain-driven design (моделируем бизнес). "Правильная" архитектура — простейшая, решающая текущие ограничения.
Когда применять
Каждый новый проект — modular monolith. Разделяйте на сервисы только когда (а) в команде > ~30 инженеров, (б) у одного компонента сильно другие требования к масштабу, (в) регуляторные границы требуют изоляции. "Архитектура" — это в основном про что вы можете дёшево менять потом; принимайте решения, откладывающие необратимость (БД на сервис — очень необратимо; границы модулей в монолите — дёшево перерисовать).
Типичные ошибки
Ловушки Монолит и модульный монолит: микросервисы для 5-инженерной команды (каждый сервис стоит ops + observability; больше дебажите RPC, чем шипите фичи); погоня за паттернами из FAANG-блогов на startup-масштабе (их ограничения не ваши); переписывание "ради clean architecture" без замеренной выгоды (clean ≠ better — только если окупается в изменяемости). Оптимизируйте под следующие 12 месяцев, не под 10x масштаб, которого нет.