Микросервисы – модный ответ почти на любой вопрос про архитектуру. На конференциях рассказывают, как Netflix и Amazon разнесли свои платформы на сотни сервисов, и зал кивает. Проблема в том, что у заказчика из госсектора нет ни команды из тысячи инженеров, ни их трафика. Архитектуру выбирают не по чужим слайдам, а по своей нагрузке, своей команде и своему регламенту. Разберём, когда дробление оправдано, а когда монолит дешевле и надёжнее.

Монолит – это не приговор

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

Для госзаказчика у монолита есть ещё один аргумент. Когда система обрабатывает персональные данные, периметр проще описать, аттестовать и защитить, если он один. Размазывать ПДн по десяткам сервисов и каналам между ними – это умножать поверхность атаки и точки утечки. Мы подробно разбирали эти риски при работе с персональными данными: чем больше границ пересекают данные, тем больше мест, где регламент 152-ФЗ можно нарушить.

Когда микросервисы окупаются

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

Второй честный повод – масштабирование отдельных компонентов. Когда пиковая нагрузка бьёт в один узел (например, генерация отчётов в конце квартала), его выносят и масштабируют горизонтально, не трогая остальное. Здесь оркестрация контейнеров перестаёт быть роскошью: мы писали, почему Kubernetes стал отраслевым стандартом для таких сценариев и как cloud-native подход меняет эксплуатацию.

Но микросервисы выставляют счёт: распределённые транзакции, сервис-дискавери, мониторинг, версионирование контрактов между сервисами. Это постоянная работа, а не разовая настройка. Команде нужна зрелость в DevOps и автоматизации, иначе вы получите распределённый монолит – все минусы дробления без его плюсов.

Как выбираем на практике

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

Третий частый ответ – гибрид: монолитное ядро плюс несколько вынесенных сервисов под конкретную нагрузку. Это нормально и чаще всего честнее, чем крайности.

Вывод

Микросервисы – не цель, а инструмент против конкретной боли: разный темп изменений, разное масштабирование, независимые релизы. Нет боли – нет смысла платить за сложность. Под госсектор и регулируемые данные стартовать с управляемого монолита почти всегда дешевле и безопаснее. Главное – чтобы архитектура отвечала вашей нагрузке и регламенту, а не чужому кейсу с конференции, поэтому бизнес-системы на заказ проектируются от фактических требований, а не от модного шаблона.