Патерни інтеграції з ERP, які не ламаються при навантаженні

ERP-інтеграції виглядають просто на схемі: система A говорить з системою B. Проблеми починаються, коли один бік гальмує, падає або накривається хвилею трафіку. Ми спостерігали, як 10-хвилинне вікно обслуговування ERP валить обробку замовлень на дві години. Ось що реально ломається і як побудувати щось, що тримає удар.

Чому синхронні інтеграції ламаються

Привабливість синхронної інтеграції очевидна: коли щось змінюється в системі A, викликай систему B. Жодних черг, middleware, асинхронної складності.

Проблема в тому, що синхронні виклики створюють жорстку зв'язність. Якщо ERP повільно відповідає або недоступний під час сплеску трафіку, ваша commerce-система або чекає (деградована продуктивність), або видає помилки користувачам. Якщо API замовлень магазину повільний, ERP не може завершити обробку замовлень.

При невеликих обсягах це зазвичай працює. При більших — особливо під час флеш-розпродажів, Black Friday або масових оновлень каталогу — точки відмови накопичуються. Ми бачили магазини, де 10-хвилинне технічне вікно ERP призводило до 400 помилок обробки замовлень і 2 годин ручної звірки.

Патерн із чергою повідомлень

Стандартне рішення — розв'язати системи через брокер повідомлень. RabbitMQ або Apache Kafka — найпоширеніші варіанти в commerce-стеках.

Патерн: коли замовлення створюється в магазині, воно публікується як повідомлення до черги. ERP-споживач читає з цієї черги та обробляє замовлення у своєму темпі. Якщо ERP недоступний, повідомлення накопичуються в черзі та обробляються, коли він повертається. Жодне замовлення не втрачається.

Той самий патерн у зворотний бік: коли запаси змінюються в ERP, публікується подія. Commerce-магазин споживає її асинхронно. Невелика затримка в оновленнях залишків прийнятна в більшості випадків; повна невдача синхронізації залишків — ні.

Ключові рішення при проєктуванні

Ідемпотентність

Доставка «хоча б один раз» — стандарт для черг повідомлень: при збоях повідомлення можуть бути доставлені більше одного разу. Ваші споживачі мають бути ідемпотентними: обробка одного й того самого повідомлення двічі має давати той самий результат, що й одноразова.

Для створення замовлення: перевіряйте, чи існує замовлення з даним зовнішнім ID, перш ніж створювати його. Для оновлення залишків: застосовуйте абсолютне значення (stock = N), а не дельту (stock += N), щоб дублюючі повідомлення не псували інвентар.

Черги мертвих листів

Не кожне повідомлення буде успішно оброблено з першої спроби — некоректні дані, таймаути downstream, тимчасові помилки. Налаштуйте чергу мертвих листів (DLQ), куди потрапляють повідомлення після N спроб. Моніторте її. Зростаючий DLQ — це ранній попереджувальний сигнал про здоров'я інтеграції, а не системний збій.

Версіонування схем

Обидві системи еволюціонують. Оновлення ERP може змінити структуру об'єкта замовлення. Якщо ваш споживач очікує стару схему, він зламається. Використовуйте реєстр схем або включайте поле версії в повідомлення. Додавайте нові поля як необов'язкові, ніколи не видаляйте обов'язкові, і підтримуйте кілька версій схем у вікнах міграції.

Що моніторити

Як мінімум, спостережуваність інтеграції має включати:

• Глибину черги з часом по топіках (зростаюча черга вказує на лаг споживача)
• Лаг споживача (різниця між останнім повідомленням і останнім обробленим)
• Кількість повідомлень у DLQ і швидкість зростання
• Час обробки по типу повідомлення (виявляйте повільних споживачів до того, як вони створять беклоги)
• Частоту помилок і класифікацію (тимчасові vs постійні)

Підключіть це до системи алертів. Глибина черги впевнено росте 15 хвилин — хтось повинен отримати сповіщення. Нові повідомлення в DLQ — автоматично створювати тікет. Не розраховуйте, що хтось згадає перевірити дашборд.

Коли підійдуть вебхуки замість черги

Черги додають інфраструктуру, яку треба тримати і обслуговувати. Для інтеграцій з невеликим обсягом, де обидві системи надійно доступні, вебхуки з логікою повторних спроб і нічним завданням звірки (порівняння станів між системами) можуть бути простішими і цілком достатніми. Ми успішно запускали таку схему на магазинах з кількасот замовлень на день.

Наша чесна думка: якщо ви обробляєте більше ~5 000 подій на годину, або у будь-якої з систем бувають планові вікна обслуговування чи аптайм нижче 99,9% — йдіть з чергою. Нижче цього — залежить від операційного комфорту вашої команди і готовності терпіти крайні випадки. Чіткої універсальної відповіді тут немає.