Масштабирование архитектуры продукта — от минимально жизнеспособного (MVP) до highload-системы — это не только технически сложно, но и требует балансирования между скоростью, стабильностью и гибкостью.

Для партнерского материала CTO Favbet Tech Андрей Черныш делится практическим опытом и на примерах рассказывает об эволюции архитектуры — от первых запусков до систем, выдерживающих десятки тысяч запросов в секунду (RPS). Он также делится подходами, которые работают лучше, и от которых стоит отказаться.

MVP нужно разрабатывать с взглядом в будущее

Когда продукт растет — увеличивается и количество пользователей, запросов и сложность бизнес-логики. В качестве примера я могу привести масштабирование API Gateway компании Favbet Tech. Этот компонент сейчас является основной точкой входа в систему.

Наша система, как это случается в 99% случаев, начиналась как монолит. Когда нагрузка начала расти, а количество клиентов увеличиваться, мы решили перейти к сервисной архитектуре. Одним из первых шагов стало выделение API Gateway. Его задача — централизованно обрабатывать все внешние запросы, маршрутизировать их к соответствующим сервисам, выполнять базовую валидацию, ограничивать количество запросов, делать аутентификацию и т. д.

После запуска API Gateway начал брать на себя наибольшую нагрузку в системе — благодаря горизонтальному масштабированию, легкому и быстрому старту, использованию языка и фреймворков для обработки запросов с минимальными задержками. Теперь API Gateway выдерживает серьезную продакшн-нагрузку и стал ключевым инструментом для контроля над инфраструктурой в масштабируемой среде.

author avatar

Андрей Черныш

CTO Favbet Tech

Начальная архитектура почти всегда монолитная. Это позволяет быстро проверить гипотезы, сократить расходы и запуститься раньше конкурентов. Однако даже на этом этапе продукт нужно разрабатывать с расчетом на потенциальный рост. Поэтому даже MVP-версия API Gateway с самого начала была готова работать с реальными пользователями и под большой нагрузкой. В нее мы уже тогда заложили ключевые функции, необходимые для стабильной работы в продакшн-среде.

Мы никогда не начинаем с идеального решения. MVP должно быть простым и доставленным быстро — но с четким пониманием, куда продукт может эволюционировать.

Принципы, которые помогли создать MVP-версию API Gateway

При создании MVP-версии API Gateway наша команда придерживалась принципов сознательно ограниченной сложности. Поэтому архитектуру MVP построили следующим образом:

  1. Модульность. Монолит, но с четкими логическими модулями.
  2. Единая база данных с логическим разделением.
  3. Простая инфраструктура, но с возможностью масштабирования без чрезмерной сложности.
  4. Базовый observability: логи, трейсы и метрики.

Поэтому уже на старте продукт имел ключевые функции, необходимые для стабильной работы в продакшн-среде:

  1. Роутинг запросов к нужным сервисам.
  2. Базовая аутентификация.
  3. Rate limiting, то есть ограничение количества запросов для защиты системы.
  4. Базовые инструменты мониторинга и метрик.

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

Как понять, что пришло время масштабироваться

Наш API Gateway с самого начала был готов к продакшену. Но только когда бизнес стал требовать большего — мы осознали, что простого роутера уже недостаточно.
MVP-версия API Gateway хорошо выполняла базовые функции, однако появилась системная потребность в гибкости и расширении контроля. Именно следующие факторы указали на то, что необходимо перейти от MVP к полноценному production-решению:

  1. Микросервисов стало больше. Статическая маршрутизация перестала быть эффективной. Требовались динамическая конфигурация, A/B-тестирование и feature flags.
  2. Разнообразие политик безопасности. API Gateway должен был «понимать» контекст каждого запроса.
  3. Запросы от команд разработки. Появилась потребность в throttling, версионировании, трейсинге, retry-логике и fallbacks.
  4. Возросла нагрузка. Мониторинг показал, что система нуждается в инструментах для предсказуемого масштабирования.
Именно тогда мы приняли решение переходить к полноценному продукту, который стал не просто прокси, а ключевым контрольным слоем между клиентом и всей нашей внутренней архитектурой.

Технические и организационные вызовы при переходе от MVP к highload

Трудности – естественная часть эволюции любого продукта. При масштабировании API Gateway мы столкнулись с рядом технических и организационных проблем:

  1. Поиск баланса между скоростью изменений и стабильностью. С переходом в продакшн появилась ответственность за надежность и бесперебойность сервиса.
  2. Рост нагрузки и сложности инфраструктуры, так как количество микросервисов увеличивалось и это требовало новых инструментов управления.
  3. Мониторинг. На раннем этапе было достаточно простого логирования. Но с переходом в production возникла потребность в детальном мониторинге метрик и уведомлениях о критических событиях.
  4. Процессы и взаимодействие между командами. В MVP команда могла быть маленькой и самодостаточной. В продакшн-фазе появилось больше зависимостей между командами и необходимость внедрения формальных процессов разработки.

Когда система переходит с условно стабильной нагрузки в highload-режим (тысячи RPS, миллионы событий в сутки), основная задача архитектора – выявить и устранить «узкие места», сохранив при этом управляемость и стабильность всей системы. Масштабирование сервиса было не радикальным. Мы эволюционно перестроили архитектуру и сосредоточились на том, чтобы устранить эти «узкие места» и одновременно сохранить управляемость системы.

Основные изменения включали такие этапы:

  1. Разделить монолит на меньшие, независимые сервисы, которые масштабируются отдельно.
  2. Перейти на асинхронную обработку данных в фоновом режиме с использованием Kafka и RabbitMQ.
  3. Внедрить Grafana Stack для детального мониторинга.
  4. Сделать автоматическое горизонтальное масштабирование на основе метрик с помощью Kubernetes.
  5. Настроить декомпозицию базы данных и внедрить распределенный кеш (DragonflyDB), чтобы снизить нагрузку на основные хранилища.
  6. Перейти на gRPC вместо REST для взаимодействия между сервисами.
  7. Вынести авторизацию в отдельный сервис с поддержкой RBAC и OPA.
Масштабирование – это не про перестройку «с нуля», а про грамотное выделение узких мест, добавление асинхронности, снижение нагрузки через кеш и обеспечение прозрачности через мониторинг. Всё это делается шаг за шагом – без шоковой перестройки, но с четким пониманием целей масштабирования.

А поскольку масштабирование – это не только технологии, но и люди, то в процессе мы адаптировали и структуру команд:

  • Перешли от универсальных к кроссфункциональным командам, которые отвечают за свой отдельный домен.
  • Создали отдельную DevOps/SRE-команду для управления инфраструктурой.
  • Внедрили внутренний портал для разработчиков.
  • Провели переквалификацию и реструктуризацию для сотрудников, которым было сложно адаптироваться к росту нагрузки.
  • Привлекли новых специалистов с нужной экспертизой.

Ошибки и важные уроки

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

В системе был один из условных монолитов, который не имел большой нагрузки и не требовал существенных изменений и частых обновлений. Мы начали агрессивно разбивать его на части, на микросервисы, да ещё и несколькими командами. Это создало избыточную сложность в CI/CD, синхронизации релизов, коммуникации между сервисами и увеличило стоимость инфраструктуры и её поддержки. Вывод, который мы сделали: архитектура должна расти вместе с бизнесом, а не опережать темпы его развития. Микросервисы – это не про «моду». Они должны быть только там, где действительно болит.

Поэтому здесь я могу дать такие советы:

  1. Не усложняйте преждевременно. Начинайте с простого, но закладывайте модульность еще на этапе архитектуры.
  2. Инвестируйте в observability: это ваши глаза и уши в системе.
  3. Автоматизируйте всё, что возможно: CI/CD, autoscaling, мониторинг. Искусственный интеллект (ИИ) поможет существенно повысить уровень автоматизации.
  4. Тестируйте под нагрузкой: регулярные load- и spike-тесты помогут выявить слабые места ещё до появления серьёзных проблем.
  5. Масштабируйте людей и процессы: архитектура растёт вместе с командами.

Highload-тестирование и важные метрики: наш гайд

В Favbet Tech мы практикуем несколько сценариев highload-тестирования с использованием, в частности, JMeter и Grafana k6:

  • Load testing: постепенное увеличение нагрузки для определения пределов производительности.
  • Spike testing: резкое увеличение трафика для проверки реакции системы.
  • Stress testing: перегрузка системы для оценки graceful degradation.
  • Soak testing: длительная работа под высокой нагрузкой для выявления утечек памяти, соединений или других проблем.

Тестирование мы проводим каждые несколько недель, даже если нет больших изменений. Например, во время spike-тестирования мы выявили проблему с исчерпанием подключений к базе данных из-за отсутствия пула соединений. Это приводило к каскадным ошибкам. Мы добавили пул подключений, оптимизировали кэш и внедрили circuit breakers.

Также мы постоянно мониторим критически важные метрики на четырёх уровнях. Вместе они позволяют видеть состояние системы и реагировать на аномалии ещё до того, как они повлияют на пользователей.

  1. Сервисные метрики
  • Latency (P50, P95, P99). Если P99 > 1s – сигнал проблемы, даже если P95 «нормальный».
  • Throughput (RPS) для оценки реальной нагрузки на компоненты.
  • Error rate (4xx, 5xx). Например, всплеск 5xx часто служит сигналом потенциальных сбоев. Метрики CPU/memory/open connections позволяют вовремя определить потребность в масштабировании – как вверх, так и вниз.
  1. Инфраструктурные метрики
  • Pod restarts в Kubernetes сигнализирует о возможной нестабильности.
  • Queue length и lags в message-брокерах.
  • DB connection usage и query latency.
  1. Бизнес-метрики
  • Request success rate – процент успешно обработанных запросов за определённый интервал времени.
  • Количество регистраций и логинов.
  • Conversion flow health показывает, доходит ли пользователь до ключевого действия (оплата, регистрация и т. д.).
  1. Метрики инцидентов
  • Alert rate.
  • MTTR (Mean Time To Recovery).
  • Deployment failure rate.

Масштабирование от MVP до highload – логический процесс роста продукта, который требует тонкого балансирования между скоростью, стабильностью и гибкостью.

author avatar

Андрей Черныш

CTO Favbet Tech

Опыт с API Gateway показал, что простота на старте, постепенные и только необходимые изменения, инвестиции в observability и правильная организация команд позволяют создать систему, которая выдержит тысячи RPS и не потеряет стабильность.

Сообщить об опечатке

Текст, который будет отправлен нашим редакторам: