Идемпотентность ломают не шлюзы — её ломают ваши костыли и память на 3 секунды

Идемпотентность ломают не шлюзы — её ломают ваши костыли и память на 3 секунды

Классическая ошибка: разработчик думает, что идемпотентность — это просто уникальный ключ в БД. Нет. Если ключ живёт только в памяти воркера, при рестарте у вас дубль. Если ключ привязан к телу запроса без нормализации — одинаковый платёж с разными заголовками превращается в «новую операцию». Документация врёт, логи — истина.

Нормальная схема держится на трёх вещах:
— idempotency key приходит извне и живёт дольше одного запроса;
— операция на сервере либо атомарна, либо защищена транзакцией;
— ответ на повтор должен быть тем же самым, а не «мы уже всё отправили, но не знаем что».

Самый мерзкий баг — когда повторный запрос не создаёт новый платёж, но триггерит второй вебхук, второй холд или второй сеттлмент. Это уже не идемпотентность, а костыль на костыле и финтехом погоняет. И да, 200 OK без сохранённого результата — не защита, а самообман.

Проверка простая: дерните один и тот же запрос десять раз, убейте воркер между попытками, подмените порядок заголовков, воспроизведите таймаут на клиенте. Если система хоть раз ведёт себя «почти правильно», идемпотентности у вас нет. Идемпотентность или смерть.