Проблема
События приходят повторно или не приходят вообще, из-за чего создаются дубли задач и несогласованные статусы.
Решение
Реализовать idempotency-key, очереди ретраев с backoff, дедупликацию и технический SLA обработки событий.
Польза
Интеграции становятся предсказуемыми, а операционные команды меньше тратят времени на разбор инцидентов.
Советы
1) Логируйте payload и результат обработки. 2) Отделите бизнес-ошибки от временных технических ошибок.
Как обрабатывать повторные события без дублей
Webhook-поставщики обычно гарантируют как минимум доставку “не менее одного раза”, а не ровно один раз. Это означает, что одно и то же событие может прийти повторно, особенно при таймауте или ошибке ответа. Поэтому обработчик должен быть идемпотентным: повторный приём не должен повторно создавать заказ, задачу или платёж, если запись уже была успешно обработана.
Что мониторить помимо самого HTTP-ответа
Для реальной надёжности мало видеть статус 200 на endpoint. Нужны метрики времени обработки, доли повторных событий, очереди на повтор, числа бизнес-ошибок и случаев, когда внешняя система приняла событие, но внутренний процесс не завершился. Именно это отделяет “endpoint жив” от “интеграция действительно доставляет корректный бизнес-результат”.