Идемпотентность: почему 90% интеграций ломают повторный запрос в самый дорогой момент

Идемпотентность: почему 90% интеграций ломают повторный запрос в самый дорогой момент

Почти все «делают идемпотентность» как наклейку на endpoint: добавили Idempotency-Key и успокоились. Это не защита, а декоративный костыль. Если ключ живёт только в памяти приложения, у вас не идемпотентность, а лотерея с двойным списанием.

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

Правильная схема скучная, как аудит PCI DSS: фиксируете ключ до обработки, атомарно связываете его с результатом, возвращаете тот же ответ на дубль и не даёте двум потокам создать две операции. И да, «мы потом дедуплицируем по order_id» — это не идемпотентность, а молитва на проде. Документация — это ложь, логи — истина.

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