Как ответить
В последнем проекте я занимался перепроектированием монолитного приложения для управления заказами в микросервисную архитектуру. Основная цель была — убрать блокировки при пиковых нагрузках (Black Friday, распродажи) и дать командам возможность независимо выкатывать фичи.
Исходный монолит работал на Java + Spring Boot, PostgreSQL, RabbitMQ. Вся логика — от приёма заказа до расчёта доставки — была в одном WAR-файле. При нагрузке 5k RPS он ложился: база не справлялась с блокировками на таблице заказов, а очередь Rabbit упиралась в лимиты по памяти.
Мы разбили систему на три сервиса:
- Order Service — приём заказов, базовая валидация, сохранение в MongoDB (для скорости записи) и публикация события в Kafka.
- Inventory Service — резервирование товаров. Использует PostgreSQL с оптимистичными блокировками (версии строк) и Redis для кэша остатков.
- Delivery Service — расчёт стоимости и сроков доставки. Тяжёлые вычисления вынесены в отдельный воркер, который читает из Kafka и пишет результат обратно.
Для коммуникации выбрали Kafka вместо RabbitMQ — нужно было гарантировать доставку событий даже при падении сервисов. Каждый сервис хранит свою базу: Order — MongoDB, Inventory — PostgreSQL, Delivery — PostgreSQL. Это позволило независимо масштабировать базы под нагрузку. Например, Inventory мы горизонтально масштабировали на три реплики с read replicas для отчётов.
Из интересных решений: внедрили Saga-паттерн для распределённых транзакций. При отказе резервирования товара Order Service отправляет компенсирующее событие в Kafka, и заказ переходит в статус «отменён». Это избавило от двухфазного коммита и блокировок.
Ещё добавили Circuit Breaker (Resilience4j) на внешние вызовы — например, к сервису платёжного шлюза. При ошибках он переключался на fallback-логику: сохранял заказ в статусе «ожидание оплаты» и ставил задачу в очередь на повтор.
Результаты: время ответа API упало с 2 секунд до 200 мс при пике 10k RPS, команды стали деплоить независимо (раньше — раз в две недели, теперь — по несколько раз в день), а время простоя в чёрную пятницу сократилось с 4 часов до нуля.