<b>Идемпотентность ломают не ретраи, а отсутствие ключа и нормального хранилища</b>

<b>Идемпотентность ломают не ретраи, а отсутствие ключа и нормального хранилища</b>

Повторный POST — это не сбой клиента, а штатный режим жизни вебхука. Сеть моргнула, хендлер отдал 500, прокси не дождался ответа, и один и тот же payload прилетает второй раз. Если обработчик не умеет отличать дубль от нового события, вы получите двойные списания, два лида, два письма и одну длинную ночь.

База простая: на входе должен быть стабильный idempotency key. Если провайдер его не даёт, собирайте ключ сами из того, что не меняется: event_id, external_id, тип события, иногда hash от полезной нагрузки. Не используйте timestamp и поля, которые могут “случайно” обновиться. Смотрим в тело запроса и решаем, что именно делает событие уникальным.

Дальше — не “проверили в коде и поехали”, а атомарная запись в хранилище. Таблица с уникальным индексом по ключу, Redis с SET NX, очередь с дедупликацией — неважно, главное, чтобы проверка и фиксация были одной операцией. Если первый воркер уже занял ключ, второй должен молча уйти в 200 OK, а не пытаться повторить бизнес-логику. Идемпотентность — это не роскошь, а база.

Отдельно держите статус обработки: received → processing → done, плюс ttl на “зависшие” записи. На 5xx отвечайте только когда реально не смогли сохранить состояние; на валидации — сразу 4xx, без ретраев. Ретрай-политика решает всё: без неё даже хороший хендлер превращается в генератор дублей.