Почему мы отказались от микросервисов на старте
Монолит — это не стыдно. Разбираем, какие проблемы микросервисы решают, а какие создают на масштабе из трёх инженеров.
Когда мы начинали строить платформу Техниума, в команде было три инженера. Первая версия архитектурного документа предлагала пять микросервисов. Мы её выбросили и написали монолит — и не жалеем.
Что обещают микросервисы
Независимое масштабирование, изоляция отказов, свобода выбора стека для каждого сервиса — всё это реальные преимущества. Но они начинают окупаться, когда у вас десятки инженеров и разные команды владеют разными частями системы.
Микросервисы решают организационную проблему — координацию между командами — а не техническую. Если команда одна, вы платите инфраструктурную цену за проблему, которой у вас нет.
Что микросервисы стоят на старте
- Распределённые транзакции вместо одной базы данных
- Сетевые вызовы вместо обычных функций — новый источник отказов
- Дублирование инфраструктуры: логирование, метрики, деплой — для каждого сервиса отдельно
- Три инженера тратят время на DevOps вместо продукта
Что мы сделали вместо этого
Один Go-модуль с чёткими внутренними границами по пакетам: matching, billing, content, notifications. Каждый пакет обменивается с другими только через явные интерфейсы — если завтра какой-то из них перерастёт монолит, вынести его в отдельный сервис будет вопросом недели, а не полугода.
package matching
type Service interface {
Assign(ctx context.Context, req Request) (Assignment, error)
}Модульный монолит дал нам скорость на старте и не закрыл дорогу к микросервисам в будущем — просто отложил это решение до момента, когда для него появится реальная причина.