Монолит vs Микросервисы

Микросервисы часто воспринимаются как стандартный подход к проектированию. Но за кулисами Netflix — компании, ставшей символом микросервисной архитектуры — критические системы работают как монолиты. При пиковых нагрузках такой подход оказывается эффективнее.

Скрытые издержки микросервисов

Network Tax

Каждая граница сервиса добавляет:

• Сериализацию и десериализацию данных
• Сетевые переходы (network hops)
• Retry-логику и таймауты
• Латентность на каждом переходе

Микросервисы:                      Монолит:

[Client] -> [API Gateway]          [Client] -> [Monolith Cluster]
               |                                  |
          [Service A]                    (Internal function calls)
               |                                  |
          [Service B]                          [DB]
               |
          [Service C]
               |
             [DB]

Каждый hop в микросервисах добавляет латентность и операционную нагрузку. Монолит маршрутизирует вызовы внутри памяти — быстрее, дешевле, проще.

Operational Complexity

Каждый новый сервис требует:

• Мониторинга и алертинга
• CI/CD пайплайна
• Incident playbook
• On-call ротации
• Документации API
• Версионирования контрактов

Debugging Nightmares

То, что раньше было одним вызовом функции, теперь — distributed trace через десятки сервисов. Найти причину проблемы в цепочке из 20 сервисов значительно сложнее, чем в стектрейсе монолита:

• Correlation IDs: каждый запрос нужно сопровождать уникальным идентификатором, который пробрасывается через все сервисы. Без этого связать логи разных сервисов невозможно.
• Distributed tracing: инструменты вроде Jaeger или OpenTelemetry помогают визуализировать путь запроса, но требуют инструментации каждого сервиса.
• Частичные сбои: в монолите запрос либо работает, либо нет. В микросервисах один из 10 сервисов в цепочке может деградировать, возвращая данные с задержкой или неполные — и это сложнее диагностировать, чем полный отказ.
• Воспроизводимость: проблема может проявляться только при определённой комбинации версий сервисов и сетевых условий, что делает воспроизведение на локальной машине затруднительным.

Модульный монолит как альтернатива

Между монолитом и микросервисами существует промежуточный вариант — модульный монолит. Код организован в изолированные модули с чёткими границами и контрактами, но деплоится как единое приложение. Это даёт:

• Чёткие границы ответственности (как у микросервисов)
• Простоту деплоя и отладки (как у монолита)
• Возможность выделить модуль в отдельный сервис позже, когда появится реальная потребность

Shopify — один из известных примеров успешного модульного монолита на Ruby on Rails, обслуживающего миллионы магазинов.

Секрет Netflix

За кулисами не всё в Netflix — микросервисы. Определённые workloads консолидированы в большие монолитные системы:

Система	Почему монолит
Recommendation Engine	Высокая нагрузка, критическая латентность
Billing	Транзакционная целостность, меньше точек отказа
Playback Authorization	Каждая миллисекунда на счету при старте видео

Когда трафик скачет (например, выход нового сезона популярного шоу в полночь), эти монолитные ядра масштабируются горизонтально эффективнее, чем десятки "болтливых" микросервисов.

Почему индустрия это упустила

1. Narrative Momentum

Микросервисы стали восприниматься как единственный «правильный» подход. Вопрос «а подходит ли это нам?» стал задаваться всё реже.

2. Org Fit Over Tech Fit

Микросервисы решают проблему масштабирования команд, не всегда — масштабирования систем. Это разные проблемы.

3. Conference Bias

Конференции showcased success stories микросервисов. Тихие победы монолитов остались неопубликованными. Никто не выступает с докладом "Мы не перешли на микросервисы и у нас всё хорошо".

Фреймворк принятия решения

Вопрос 1: Сколько у вас команд?

Одна команда?
└── Предпочтите монолит
    • Быстрее итерации
    • Проще операции
    • Меньше координации

Много команд?
└── Микросервисы могут уменьшить friction
    • Независимые деплои
    • Автономия команд
    • Чёткие границы владения

Вопрос 2: Что является bottleneck — трафик или люди?

Bottleneck — трафик?
└── Монолит часто выигрывает
    • Меньше сетевых переходов
    • Проще масштабирование
    • Ниже латентность

Bottleneck — люди?
└── Микросервисы могут помочь
    • Независимая работа команд
    • Меньше merge conflicts
    • Быстрее onboarding в отдельный сервис

Матрица решения

	Мало команд	Много команд
Bottleneck — трафик	Монолит	Модульный монолит или крупные сервисы
Bottleneck — люди	Монолит (пока)	Микросервисы

Резюме

Ключевые инсайты:

• Netflix использует монолиты для критических систем (рекомендации, биллинг, playback)
• Каждая граница сервиса — это Network Tax (сериализация, hops, retries)
• Микросервисы решают проблему масштабирования команд, не систем
• Решение зависит от bottleneck: трафик → монолит, люди → микросервисы
• "Современно" ≠ "правильно для вашего случая"