Почему Idempotency‑Key не спасает от двойного списания и как это исправить
Клиент отправил платёж, не дождался ответа и повторил запрос. На сервере предусмотрен Idempotency-Key , тесты проходят, но деньги всё равно списываются дважды. Проблема возникает, когда второй запрос приходит до завершения первого: оба обработчика успевают проверить ключ и запустить оплату. Разберём, как закрыть эту гонку с помощью PostgreSQL, что делать при падении процесса и почему даже правильно реализованная идемпотентность внутри сервиса не всегда спасает от повторного списания. Разобрать решение
https://habr.com/ru/companies/otus/articles/1095234/
#postgresql #транзакции #обработка_ошибок #отказоустойчивость #race_condition #идемпотентность #конкурентные_запросы #двойное_списание #idempotencykey #платежный_api