Как масштабировать архитектуру под рост продукта: от MVP до highload

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

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

Содержание

• 1 MVP нужно разрабатывать с взглядом в будущее
• 2 Принципы, которые помогли создать MVP-версию API Gateway
• 3 Как понять, что пришло время масштабироваться
• 4 Технические и организационные вызовы при переходе от MVP к highload
• 5 Ошибки и важные уроки
• 6 Highload-тестирование и важные метрики: наш гайд

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

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

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

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