Когда монолит действительно пора делить

Сервис вырос до сотни модулей, сборка занимает вечность, а схему базы уже никто не помещает в голове.

Кажется, пора переходить на микросервисы.

Но размер сам по себе — слабый архитектурный аргумент. Большой монолит может годами оставаться удобным. А пять маленьких сервисов — превратиться в распределённый монолит, который падает по частям, а релизится всё равно целиком.

Я бы смотрел не на количество строк кода, а на то, живут ли части системы по разным правилам.

Вот несколько признаков.

Разные причины изменений

Одна часть меняется из-за требований бухгалтерии, другая — из-за экспериментов продуктовой команды, третья — при подключении новых партнёров.

Если изменения регулярно затрагивают только одну область, а остальные приходится собирать, тестировать и выкатывать за компанию, внутри монолита уже появились самостоятельные контуры.

Разные профили нагрузки

Каталог в основном читает данные. Биллинг обрабатывает транзакции. Генерация отчётов создаёт тяжёлую фоновую нагрузку.

Масштабировать весь сервис ради одного горячего участка дорого и неудобно. Особенно когда отчёт за прошлый квартал начинает конкурировать за ресурсы с оформлением заказов.

Разная скорость релизов

Одна часть продукта требует нескольких релизов в день. Другая меняется раз в месяц и должна проходить длинный цикл проверок.

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

Разные владельцы

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

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

Независимые failure domains

Падение рекомендаций не должно мешать оформить заказ. Ошибка в генерации документов не должна останавливать авторизацию.

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

При этом вынести код в отдельный процесс недостаточно. Если сервисы используют одну базу, синхронно вызывают друг друга по длинной цепочке и релизятся только согласованным набором, failure domain остаётся общим. Просто теперь у него появился HTTP.

Именно поэтому аргумент «микросервисы сейчас делают все» ничего не говорит об архитектуре.

Разделение добавляет сетевые ошибки, контракты, наблюдаемость, версионирование, сложные тесты и новые сценарии отказа. За эту сложность стоит платить только тогда, когда она покупает независимость.

Не потому, что сервис стал большим.

А потому, что его части меняются, нагружаются, выпускаются, управляются и ломаются по-разному.