Микросервисы — плохой выбор по умолчанию для 94% команд.
Микросервисы — плохой выбор по умолчанию для 94% команд. Зачем разбивать приложение на набор сервисов, которым нужно общаться через сеть. На бумаге это выглядит как «правильный» подход. Масштабирование звучит привлекательно. Но на практике я видел, как это ломается, шесть раз. Команды из 5 инженеров поднимали 11 сервисов с несколькими очередями сообщений. Всё становилось медленнее. Деплой, который занимал минуты, растягивался до 35 минут из-за зависимостей. Отладка превращалась в кошмар: один баг — и приходится трейсить запрос через несколько сервисов и кодовых баз. Сложность не уменьшилась. Она просто распределилась. Микросервисы — это решение под масштабирование, но большинство команд внедряют их слишком рано, когда проблемы масштаба ещё нет. Если ты всё ещё работаешь на localhost, основная проблема — не масштаб. Это стабильный релиз. Когда микросервисы имеют смысл: - команды блокируют работу друг друга - части системы требуют независимого масштабирования - есть нормальная трассировка в проде, и можно отлаживать без угадывания Если этого нет — платишь налог распределённых систем без реальной выгоды. Начинай с монолита и держи модульность. Делить стоит только тогда, когда связность начинает тормозить разработку. Большинство обсуждений «нам нужны микросервисы» на деле не про архитектуру. Они про грязную кодовую базу или болезненные деплои. Сначала решаются эти проблемы. Простые системы легче понимать. Перегруженные обычно разваливаются под собственным весом. Java Библиотека | Мы в Телеграм