Микросервисы или монолит: как мы выбираем архитектуру в 2025
«Нам нужны микросервисы» — одна из самых частых фраз, которую мы слышим на первой встрече с потенциальным клиентом. Обычно это означает, что человек либо читал статьи о Netflix и Uber, либо пострадал от монолита в прошлом.
Правда в том, что большинству проектов в России микросервисы не нужны — по крайней мере, в начале. И это нормально. Хороший модульный монолит на Spring Boot справится с нагрузкой большинства B2B-продуктов, его проще разрабатывать и отлаживать.
Но иногда микросервисы действительно оправданы. Вот как мы принимаем это решение.
Когда монолит — правильный выбор
Монолит — это не техдолг по умолчанию. Это осознанное архитектурное решение, которое подходит для большинства проектов на старте и даже на масштабе.
Выбирайте монолит, если: команда до 10 человек, нагрузка до 5–10к RPM, домен понятен и стабилен, нет требования независимых деплоев для разных частей системы.
Хорошо структурированный монолит на Spring Boot с чёткими границами доменов легко распилить на сервисы позже, когда появится реальная необходимость. Мы называем это «модульный монолит» — и часто именно так рекомендуем начинать.
Когда микросервисы оправданы
Нагрузка 50к+ RPM с сильно различающимися требованиями к масштабированию разных частей. Несколько независимых команд, которые должны деплоиться без координации. Разные части системы имеют принципиально разные нефункциональные требования (например, ML-сервис vs транзакционная логика).
Из нашего опыта: порог, при котором микросервисы начинают давать реальный профит, — это 5–7 разработчиков и 20–30к RPM. Ниже этого — вы платите за операционную сложность, не получая выгод масштабируемости.