Монолитный код все еще актуален, или будущее за микросервисами?

Монолитная архитектура не просто актуальна, а часто является оптимальным выбором. Будущее — за прагматичным подходом, а не за слепым следованием тренду на микросервисы.

Я выбираю монолит, когда:

• Команда небольшая (1-3 разработчика), а скорость — критична. На старте проекта накладные расходы на развертывание, мониторинг и отладку распределённой системы убивают скорость разработки.
• Предметная область (domain) тесно связана. Если сущности в системе (например, User, Order, Invoice) постоянно взаимодействуют, разделение их по сервисам создаст больше проблем (сетевые вызовы, distributed transactions), чем решит.
• Требования к производительности крайне высоки. Локальные вызовы внутри монолита всегда быстрее сетевых RPC между микросервисами.

Пример современного монолита (Java/Spring): Чётко модульная структура внутри одной кодовой базы и одного deployable artifact.

monolith-app/
├── src/main/java/com/example/
│   ├── user/          # Модуль пользователей
│   ├── order/         # Модуль заказов
│   ├── billing/       # Модуль биллинга
│   └── shared/        # Общие DTO, утилиты
└── pom.xml            # Один артефакт, один деплой

Я перехожу к микросервисам, когда:

• Разные части системы имеют принципиально разные требования к масштабированию. Например, сервис генерации PDF-отчётов требует много CPU, а сервис аутентификации — нет. Их можно масштабировать независимо.
• Команды большие и автономные. Каждая команда может владеть своим сервисом, выбирать свой стек технологий и цикл разработки.
• Требуется повышенная отказоустойчивость. Падение одного сервиса не должно валить всю систему.

Вывод: Начинать с монолита — это не технический долг, а часто лучшая практика. Микросервисы — это дорогое архитектурное решение, которое должно быть принято осознанно, когда преимущества перевешивают операционные издержки. Модульный монолит (Modulith) — отличный компромисс, позволяющий позже относительно безболезненно выделить модули в отдельные сервисы, если потребуется.