Інтеграції майже завжди “at‑least‑once”
Провайдери можуть повторювати webhooks, мережа може падати, клієнт може натиснути “оплатити” двічі. Exactly‑once у реальному світі майже недосяжний, тому потрібна ідемпотентність.
1) Idempotency‑Key на критичні операції
- Створення платежу/інвойсу/відправки.
- Ключ має бути стабільним для повторів (orderId + type).
2) Дедуплікація webhooks
- Зберігай eventId + статус обробки.
- Обробка має бути транзакційною: “записали, що обробили” разом із змінами.
3) Гонки і порядок подій
Подія “delivered” може прийти раніше “in_transit”. Потрібні правила монотонності статусів і перевірки валідних переходів.
4) Спостережуваність
Метрики: кількість дубль‑подій, ретраїв, dead‑letter. Без цього неможливо зрозуміти, де система “підтікає”.
Підсумок
Ідемпотентність робить інтеграції керованими: ретраї і повторні webhooks перестають створювати дублікати, а підтримка отримує прозорі інструменти.