# Монолит или микросервисы для команды из пяти человек: как выбрать

> Монолит или микросервисы для команды из пяти человек? Используйте простые правила решения, опираясь на скорость релизов, планы найма, требования комплаенса и нагрузку поддержки.

## Почему этот выбор кажется больше, чем есть на самом деле

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

«Монолит или микросервисы» часто воспринимают как вопрос престижа. Обычно это не так. Лучше та конфигурация, которая позволяет вашей команде выпускать, отлаживать и поддерживать продукт с наименьшими тормозами.

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

Мода делает выбор масштабнее, чем он есть. Малые команды копируют компании с десятками инженеров, строгими аудит‑правилами или круглосуточной поддержкой, а потом удивляются, почему релизы замедлились. Простой монолит часто — лучший дефолт, потому что ежедневная работа остаётся в одном месте. Один кодбейс проще тестировать, проще объяснить новому сотруднику и проще править, когда в четверг после обеда клиент попросит неожиданное изменение.

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

## Начните со скорости релизов

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

Оглянитесь на последние 4–8 недель и посчитайте реальные релизы, не запланированные. Если один кодбейс позволяет вам выкатывать исправления и фичи несколько раз в неделю без серьёзных трений — защищайте это. Часто монолит выигрывает здесь, потому что есть один репозиторий, один путь тестирования и один путь деплоя.

Потом ищите повторяющиеся блокеры. Задержала ли изменение в платёжном модуле исправление поиска? Блокировала ли одна рискованная зона несвязанную работу более одного раза? Одна плохая неделя много не значит. Важна закономерность.

Разделение начинает иметь смысл, когда одна и та же часть продукта постоянно замедляет работу, не связанную с ней. Возможно, этой области нужен собственный ритм релизов, правила утверждения или режим поддержки. Если она ещё и порождает срочные инциденты — аргумент становится сильнее.

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