Привет, форумчане! Меня зовут Алексей, я двенадцать лет пишу бэкенд и последние пять из них провожу в чужих кодовых базах в роли архитектора или техлида. За это время я дважды ломал вполне живые монолиты и один раз собирал обратно то, что команда сгоряча разнесла на пятьдесят сервисов. Так что тему микросервисов против монолита я знаю не по статьям, а по бессонным ночам и откатам в три часа ночи.
Начну с непопулярного в 2025 году тезиса: монолит не умер и не собирается. Хорошо собранный модульный монолит на современном стеке выдерживает десятки тысяч запросов в секунду, деплоится за минуты и не требует армии платформенных инженеров. В одном из моих проектов монолит с аккуратными модулями и одним контейнером жил четыре года, к нему подключили девяносто разработчиков, и никто не страдал. Проблемы начинались не из-за архитектуры, а из-за отсутствия границ внутри кода и договорённостей между командами.
Первый раз я решился на разбор в 2021 году. Сигналы были очень конкретные: сорок разработчиков в семи командах, релизный поезд раз в две недели, и каждый релиз превращался в трёхдневный ритуал согласований. Один модуль отвечал за биллинг, рекомендации и уведомления одновременно, и любая правка в рассылке могла уронить платежи. Мы вынесли биллинг и уведомления в отдельные сервисы, оставили ядро как модульный монолит и в итоге сократили время до продакшена с двух недель до одного дня. Это сработало, но не потому, что микросервисы сами по себе хороши, а потому что мы разделили их строго по границам команд и зон ответственности.
Второй опыт был болезненным, и о нём стоит рассказать подробнее. Другая компания решила, что раз микросервисы модно, значит нужно вынести всё. Получилось сорок сервисов, у каждого свой репозиторий, свой пайплайн, свои миграции и свой дежурный. Через полгода у нас был классический распределённый монолит: общие таблицы, синхронные вызовы по цепочке из восьми сервисов и невозможность понять, где именно теряется запрос. Мы не получили независимых деплоев, зато получили три сотни сетевых вызовов на один пользовательский сценарий и рост расходов на инфраструктуру втрое. Пришлось честно признаться, что проблема была в организации, а не в языке программирования.
Так когда же ломать архитектуру? Я выработал для себя простой список вопросов, и если команда не отвечает утвердительно хотя бы на три из них, я не трогаю монолит. Первое: есть ли минимум три независимые команды, которым правда мешают друг другу. Второе: нужны ли разным частям системы разные режимы нагрузки и масштабирования, например поиску десять подов, а админке один. Третье: требуется ли изолировать сбой, чтобы падение рекомендаций не роняло оплату. Четвёртое: готовы ли вы вкладываться в наблюдаемость, трассировку, контракты и платформенную команду, потому что без этого сервисы станут только дороже. Пятое: есть ли требование выпускать части продукта в разном темпе. Если ответы размытые, скорее всего вам нужен не отдельный сервис, а порядок в модулях.
Мой практический рецепт для тех, кто всё же решился. Начинайте всегда с модульного монолита: чёткие модули, запрет на прямые обращения в чужие таблицы, публичные интерфейсы и версионируемые API внутри процесса. Потом вынимайте по одному модулю, лучше всего по той границе, где боль ощущается сильнее всего, например фоновые задачи, интеграции, биллинг. Не выносите то, что меняется вместе. Добавляйте сервис только тогда, когда у него есть владелец, отдельный жизненный цикл и метрики, по которым видно его здоровье. И обязательно фиксируйте контракты до кода, иначе через год вы получите сорок маленьких монолитов, которые не умеют друг с другом разговаривать.
Отдельно скажу про бизнес, потому что именно здесь чаще всего ломается логика. Микросервисы это не техническое решение, а организационное, и стоят они не только денег на серверы, но и скорости принятия решений, найма сильных инженеров и времени на согласования. Мода 2025 года подталкивает всех к распределённым системам, но если у вас десять разработчиков и один продукт, вы просто обменяете простой код на сложную инфраструктуру. Я видел и обратную ситуацию, когда монолит тормозил компанию и стоил ей больше, чем вся платформа. Разница всегда в одном: считайте, сколько денег и времени приносит независимость выпуска именно вашей команде.
Мой итог за 2025 год такой. Архитектуру ломают не ради моды, а ради людей и скорости, и лучший вариант почти всегда лежит посередине: крепкое ядро в виде модульного монолита плюс несколько честно выделенных сервисов там, где это окупается. Начинайте с боли, измеряйте результат, будьте готовы откатить решение, если оно не принесло пользы, и не верьте обещаниям, что микросервисы автоматически сделают вас быстрее.
А теперь интересно послушать вас: какой подход победил в вашем проекте и что стало тем самым сигналом, после которого вы решились менять архитектуру? Поделитесь историей, буду рад и поддержать, и поучиться у вашего опыта!
Начну с непопулярного в 2025 году тезиса: монолит не умер и не собирается. Хорошо собранный модульный монолит на современном стеке выдерживает десятки тысяч запросов в секунду, деплоится за минуты и не требует армии платформенных инженеров. В одном из моих проектов монолит с аккуратными модулями и одним контейнером жил четыре года, к нему подключили девяносто разработчиков, и никто не страдал. Проблемы начинались не из-за архитектуры, а из-за отсутствия границ внутри кода и договорённостей между командами.
Первый раз я решился на разбор в 2021 году. Сигналы были очень конкретные: сорок разработчиков в семи командах, релизный поезд раз в две недели, и каждый релиз превращался в трёхдневный ритуал согласований. Один модуль отвечал за биллинг, рекомендации и уведомления одновременно, и любая правка в рассылке могла уронить платежи. Мы вынесли биллинг и уведомления в отдельные сервисы, оставили ядро как модульный монолит и в итоге сократили время до продакшена с двух недель до одного дня. Это сработало, но не потому, что микросервисы сами по себе хороши, а потому что мы разделили их строго по границам команд и зон ответственности.
Второй опыт был болезненным, и о нём стоит рассказать подробнее. Другая компания решила, что раз микросервисы модно, значит нужно вынести всё. Получилось сорок сервисов, у каждого свой репозиторий, свой пайплайн, свои миграции и свой дежурный. Через полгода у нас был классический распределённый монолит: общие таблицы, синхронные вызовы по цепочке из восьми сервисов и невозможность понять, где именно теряется запрос. Мы не получили независимых деплоев, зато получили три сотни сетевых вызовов на один пользовательский сценарий и рост расходов на инфраструктуру втрое. Пришлось честно признаться, что проблема была в организации, а не в языке программирования.
Так когда же ломать архитектуру? Я выработал для себя простой список вопросов, и если команда не отвечает утвердительно хотя бы на три из них, я не трогаю монолит. Первое: есть ли минимум три независимые команды, которым правда мешают друг другу. Второе: нужны ли разным частям системы разные режимы нагрузки и масштабирования, например поиску десять подов, а админке один. Третье: требуется ли изолировать сбой, чтобы падение рекомендаций не роняло оплату. Четвёртое: готовы ли вы вкладываться в наблюдаемость, трассировку, контракты и платформенную команду, потому что без этого сервисы станут только дороже. Пятое: есть ли требование выпускать части продукта в разном темпе. Если ответы размытые, скорее всего вам нужен не отдельный сервис, а порядок в модулях.
Мой практический рецепт для тех, кто всё же решился. Начинайте всегда с модульного монолита: чёткие модули, запрет на прямые обращения в чужие таблицы, публичные интерфейсы и версионируемые API внутри процесса. Потом вынимайте по одному модулю, лучше всего по той границе, где боль ощущается сильнее всего, например фоновые задачи, интеграции, биллинг. Не выносите то, что меняется вместе. Добавляйте сервис только тогда, когда у него есть владелец, отдельный жизненный цикл и метрики, по которым видно его здоровье. И обязательно фиксируйте контракты до кода, иначе через год вы получите сорок маленьких монолитов, которые не умеют друг с другом разговаривать.
Отдельно скажу про бизнес, потому что именно здесь чаще всего ломается логика. Микросервисы это не техническое решение, а организационное, и стоят они не только денег на серверы, но и скорости принятия решений, найма сильных инженеров и времени на согласования. Мода 2025 года подталкивает всех к распределённым системам, но если у вас десять разработчиков и один продукт, вы просто обменяете простой код на сложную инфраструктуру. Я видел и обратную ситуацию, когда монолит тормозил компанию и стоил ей больше, чем вся платформа. Разница всегда в одном: считайте, сколько денег и времени приносит независимость выпуска именно вашей команде.
Мой итог за 2025 год такой. Архитектуру ломают не ради моды, а ради людей и скорости, и лучший вариант почти всегда лежит посередине: крепкое ядро в виде модульного монолита плюс несколько честно выделенных сервисов там, где это окупается. Начинайте с боли, измеряйте результат, будьте готовы откатить решение, если оно не принесло пользы, и не верьте обещаниям, что микросервисы автоматически сделают вас быстрее.
А теперь интересно послушать вас: какой подход победил в вашем проекте и что стало тем самым сигналом, после которого вы решились менять архитектуру? Поделитесь историей, буду рад и поддержать, и поучиться у вашего опыта!