Как мы ускорили backend e-commerce в 44 раза: технический разбор
В конце 2023-го к нам пришёл e-commerce клиент с классической проблемой: в обычные дни система работает нормально, в периоды распродаж — падает под нагрузкой. Время ответа 8 секунд в пике. Раз в сезон — полное падение на 20–40 минут.
Backend был написан на PHP, стартовал в 2017 году как стартап MVP и с тех пор «просто дорабатывался». Никто не трогал архитектуру — только добавляли фичи.
Через 5 месяцев работы: среднее время ответа 180 мс, пик 100к RPM без деградации, деплой за 8 минут вместо 2,5 часов. Рассказываю, как мы это сделали.
Диагностика: что именно тормозило
Первые 2 недели — только наблюдение и анализ. Профилировали production-трафик через New Relic, анализировали slow query log PostgreSQL, изучали код.
Топ-3 причины тормозов: N+1 проблема в ORM при загрузке каталога (для каждого товара — отдельный запрос характеристик), одна PostgreSQL без read-реплик при 80% read-трафика, синхронные вызовы внешних сервисов (склад, платёжный шлюз) в основном потоке запроса.
Последнее особенно болезненно: если склад отвечал за 3 секунды, страница корзины тоже отвечала за 3 секунды.
Strangler Fig: поэтапная миграция без остановки
Полная перезапись за 5 месяцев невозможна. Выбрали паттерн Strangler Fig: постепенно вырезаем куски монолита и заменяем Java-сервисами. Трафик постепенно переключается через API Gateway.
Начали с каталога — самая читаемая часть, легко изолируется, нет транзакционной логики. Каталог-сервис на Spring Boot + Redis-кэш для горячих данных. Результат через 2 недели: время загрузки каталога 45 мс вместо 1200 мс.