16 июля 2026
502
Алексей Додонов, эксперт с 20-летним опытом в ИТ, на сквозном кейсе разобрал эволюцию архитектуры стартапа по продаже авиабилетов — от монолита до распределённой системы, и как команда решала проблемы производительности на каждом этапе.
Нотация C4: как описывать архитектуру
C4 — четырёхуровневая модель: Context (для бизнеса), Container (для архитекторов), Component (для разработчиков) и Code (UML, в вебинаре не рассматривался). Ключевое правило: называть одни и те же элементы одинаково на всех уровнях, иначе диаграммы теряют связность.Отчёты вешают базу — CQRS на уровне БД
У стартапа был монолит на PHP с одной MySQL. Отчёты для бизнес-пользователей грузили общую базу и мешали интерфейсу. Решение: мастер на запись и два слейва на чтение. Отчёты ушли на отдельный слейв — интерфейс перестал тормозить.Пустые письма после регистрации — CAP-теорема
После внедрения репликации у некоторых пользователей в письмах был пустой шаблон без их данных. Причина: из-за задержки репликации чтение из слейва возвращало пустые данные, хотя в мастер они уже были записаны. Решение: убрали один слейв, монолит снова читает и пишет в мастер.Redis не масштабируется — переход на DynamoDB
Redis не справлялся с пиковыми нагрузками и не умел автомасштабироваться. А обновление last_activity в MySQL съедало до 30% ресурсов БД. Сессии и пользовательские данные перенесли в DynamoDB — дешевле, масштабируется из коробки, надёжность 5 девяток. А Redis остался только для кэширования.Шардирование сессий
Запросы к DynamoDB стали узким местом, масштабировать кластер стало дорого. Сессии шардировали по ID на два независимых кластера с маршрутизацией через ShardManager. Важно: ключ должен давать равномерное распределение — если выбрать страну пользователя, получим перекос.Горячее и холодное хранилище для отчётов
Систему отчётов отделили от монолита, данные переливаются через ETL (Apache Airflow). Внутри — два хранилища: горячее (быстрое, дорогое) для данных за последние 6–12 месяцев и холодное (медленное, дешёвое) для всей истории. Раз в неделю данные переносятся из горячего в холодное.Проактивное управление производительностью (SPE)
От реактивных «чиним, когда упало» перешли к проактивному подходу. Методика SPE: определить целевые показатели (SLA, SLO, RPS), выбрать критичные сценарии, нарисовать архитектуру, выявить узкие места. Пример: цель — увеличить продажи в 3 раза. Критичный сценарий — покупка билета. Основной риск — интеграционная шина, а не монолит и не Kafka.Из Q&A: как не упираться в интеграционную шину
Если шина становится узким горлышком — выделить под каждого провайдера отдельный микросервис и распараллелить нагрузку. Если провайдер тормозит — поднимать вопрос о рейт-лимитах. Если захлёбывается — Circuit Breaker убирает его из выдачи до восстановления.Главный вывод
Архитектура усложняется вместе с бизнесом. Каждое решение рождает новые ограничения. Важно не просто «починить», а внедрить системный процесс управления производительностью. Нотация C4 и методика SPE помогают делать это от бизнес-целей до конкретных узких мест.Больше деталей — в записи вебинара.