Повторный webhook — не баг, если идемпотентность у вас не на словах

Повторный webhook — не баг, если идемпотентность у вас не на словах

Смотрим в тело запроса: ретрай от провайдера, двойной клик пользователя или сетевой дубль должны приводить к одному и тому же состоянию. Не к двум платежам, не к двум лидам, не к двум письмам.

Базовый паттерн: внешний event_id или request_id кладём в таблицу уникальных ключей. При входе:
— если ключ уже есть, возвращаем 200/204 и не трогаем пайплайн;
— если ключ новый, атомарно записываем его и запускаем обработку.
Идемпотентность — это не роскошь, а база.

Если полезная нагрузка не содержит стабильного идентификатора, генерируйте свой fingerprint: hash от значимых полей, без мусора вроде timestamp и подписи. Для критичных операций держите TTL на ключи и отдельный стор для дедупликации. Прокидываем стейт через метаданные, а не через память хендлера.

Снаружи это выглядит скучно: `INSERT ... ON CONFLICT DO NOTHING`, `SETNX`, уникальный индекс, очередь с dedup key. Внутри — защита от повторной доставки, ретраев и частично упавших воркеров. Ловим 5xx на ровном месте только тогда, когда система действительно сломана, а не потому что поставщик решил дёрнуть один и тот же запрос трижды.

Пишите обработчик так, будто следующий запрос уже пришёл. И тогда повторная доставка станет шумом, а не инцидентом.