Рефакторинг backend для e-commerce платформы: с 8 секунд до 180 мс
Перевели высоконагруженный интернет-магазин с монолита на микросервисную архитектуру. Ускорили среднее время ответа в 44 раза.
🎯 Задача
Крупный интернет-магазин товаров для ремонта работал на PHP-монолите, разработанном 6 лет назад. В обычные дни система справлялась, но в периоды распродаж (Чёрная пятница, майские праздники) среднее время ответа вырастало до 8 секунд, а раз в сезон случались полные падения на 20–40 минут.
Горизонтальное масштабирование монолита упиралось в базу данных: одна PostgreSQL не справлялась с 80–100 тысячами запросов в минуту. Деплой занимал 2,5 часа и требовал полной остановки сервиса.
Команда решила перейти на Java-стек и микросервисную архитектуру, но не хотела переписывать всё сразу — нужен был поэтапный переход без остановки продаж.
💡 Решение
Мы предложили стратегию «Strangler Fig»: постепенно вырезать функциональность из монолита и переносить в отдельные Java-сервисы, не трогая остальное. Это позволяло деплоить изменения независимо и сразу получать ценность от каждого этапа.
Разбили систему на 7 доменных сервисов: каталог, корзина, заказы, пользователи, платежи, поиск, уведомления. Каждый сервис — своя база данных, своя зона ответственности.
Критически важным было обеспечить консистентность данных между сервисами. Для этого использовали Kafka и паттерн Saga для распределённых транзакций — заказ не теряется, даже если один сервис временно недоступен.
⚙️ Реализация
Этап 1 — Каталог и поиск (6 нед.)
Самая читаемая часть системы. Вынесли сервис каталога, добавили Elasticsearch для поиска. Время ответа каталога упало с 1.2 с до 45 мс.
Этап 2 — Заказы и платежи (8 нед.)
Критическая транзакционная часть. Реализовали Saga-паттерн через Kafka. Интеграция с ЮKassa и Sberbank Acquiring через единый платёжный сервис.
Этап 3 — Инфраструктура (4 нед.)
Kubernetes-кластер, настройка автоскейлинга (HPA), Prometheus + Grafana для мониторинга, ELK для логов. CI/CD через GitLab — деплой за 8 минут вместо 2,5 часов.
Этап 4 — Нагрузочные тесты и оптимизация (3 нед.)
Нагрузочное тестирование с Gatling. Нашли и устранили N+1 проблемы в ORM, добавили кэширование Redis для горячих данных. Профилировали JVM.
📊 Результаты
Первая распродажа после запуска новой архитектуры прошла без единого инцидента. Пиковая нагрузка в 97 000 RPM, среднее время ответа 180 мс. Команда разработки теперь выпускает фичи независимо — без согласования окон деплоя.
Затраты на инфраструктуру снизились на 30%: автоскейлинг позволяет держать минимальное количество pod'ов вне пиков и быстро масштабироваться при нагрузке.