<b>Повторный вебхук не должен создавать второй платёж, заказ или лид</b>

<b>Повторный вебхук не должен создавать второй платёж, заказ или лид</b>

Смотрим в тело запроса: если источник шлёт один и тот же event дважды, хендлер обязан вернуть тот же результат, а не плодить дубль. Идемпотентность — это не роскошь, а база. Самый надёжный паттерн: idempotency_key из внешнего event_id, сохранённый в БД до выполнения бизнес-логики.

Дальше — жёсткий unique index по ключу. Алгоритм простой: 1) пришёл запрос; 2) проверили ключ; 3) если запись уже есть — отдали сохранённый ответ; 4) если нет — создали запись со статусом processing, выполнили операцию, сохранили результат. Если сервис упал между шагами, ретрай-политика решает всё, но только при наличии фиксации состояния.

Не путайте идемпотентность с «не делать ничего повторно». Внешний API может прислать тот же payload с новым delivery_id, поэтому дедупликация по транспортным метаданным ломается при первой же переотправке. Прокидываем стейт через метаданные: event_id, source, entity_id, hash полезной нагрузки — и сравниваем не только факт дубля, но и расхождение содержимого. Если payload изменился, это уже не повтор, а конфликт.

Ещё одна типовая ошибка: писать в очередь до проверки уникальности. В итоге у вас два job’а, два воркера и один несчастный заказ. Ловим 5xx на ровном месте, если БД недоступна, и не подтверждаем приём, пока запись об идемпотентности не зафиксирована.

Практика одна: сначала ключ, потом действие, потом ответ. Всё остальное — генератор дублей.