Проблема
Великий інтернет-магазин зі 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-операцій