Проблема
Крупный интернет-магазин с 150 000 товаров и 5 000 заказов в день постоянно синхронизировал данные между магазином, PIM-системой и CRM — товары, остатки, заказы, цены, данные клиентов и атрибуты. Все интеграции были построены на синхронных REST API вызовах. В часы пиковой нагрузки интеграционный слой рушился: таймауты накапливались, заказы терялись или дублировались, остатки расходились, и каждый сбой каскадно тянул за собой следующий. В обычную неделю 12–15% API-запросов просто не проходили, а операционная команда каждое утро часами латала данные вручную.
Что мы сделали
- Аудит интеграций — Описали все 27 потоков данных между магазином ↔ PIM ↔ CRM. Определили четыре критических узких места: массовый импорт 150К товаров, синхронизация остатков по 3 складам в реальном времени, колбэки статусов заказов и распространение 80+ пользовательских атрибутов.
- Миграция на RabbitMQ — Заменили каждый синхронный REST-вызов асинхронными очередями сообщений. Каждый тип данных — товары, остатки, заказы, атрибуты — получил собственный exchange, топологию маршрутизации и выделенных консьюмеров с независимым масштабированием.
- Retry и dead-letter логика — Построили трёхуровневую стратегию повторов: немедленный retry, отложенный retry (экспоненциальный backoff до 30 мин) и dead-letter очередь с алертами в Slack. Ни одно сообщение не теряется — каждый сбой отслеживается и перерабатывается.
- Стек наблюдаемости — Развернули централизованное логирование (ELK), дашборды очередей в реальном времени и автоматические алерты. Команда видит весь жизненный цикл сообщения — от отправки до подтверждения — в одном месте. Среднее время реакции на инциденты упало с часов до минут.
Результат
“Раньше каждый понедельник начинался с разбора сбоев за выходные. Теперь 200 000 сообщений в день проходят через очереди без единого сбоя. Операционная команда наконец доверяет данным — и мы не потеряли ни одного заказа за три месяца.”
Даниэль Кравчук — Руководитель eCommerce-операций