Идемпотентность при повторных вебхуках: проблема которую игнорируют до первого инцидента

Идемпотентность при повторных вебхуках: проблема которую игнорируют до первого инцидента

Представь: платёжная система подтверждает оплату, твой сервер принял хук, записал транзакцию — и вернул 500 из-за ошибки в следующей строке кода. Платёжка не знает что ты получил данные, она ретраит. Ты записываешь транзакцию второй раз.

Результат: задвоенное начисление, конфликт в БД или двойная выплата аффилиату.

Решение — идемпотентный приёмник. Каждый хук имеет уникальный event_id (обычно в заголовках или теле). Алгоритм:
1. Получил хук → проверь event_id в таблице processed_events
2. Если уже есть — верни 200 без обработки
3. Если нет — обработай, запиши event_id, верни 200

Важно: запись event_id и обработка должны быть в одной транзакции БД. Иначе при падении между шагами ты получишь либо дубль, либо потерянное событие.

Для высокой нагрузки — Redis вместо БД: SET event_id 1 EX 86400 NX. Атомарная операция, возвращает nil если ключ уже существует.

TTL на хранение processed_events: 7 дней. Платформы ретраят максимум 72 часа, запас достаточный.