\Idempotency-Key\ в OpenAPI — ещё не доказательство идемпотентности.

Клиент отправляет \POST /payments, не дожидается ответа и повторяет запрос, пока первый ещё выполняется. Если обработчик сначала проверяет ключ, потом вызывает платёжный сервис, а запись о ключе создаёт в конце, оба запроса могут пройти проверку. Уникальный индекс защитит таблицу ключей — но не от повторного внешнего списания, которое уже произошло.

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

Разбор со сценариями гонки и отказов: https://habr.com/ru/companies/otus/articles/1095234/

#Архитектура #КорпоративнаяАрхитектура #Интеграция #API #Отказоустойчивость