Платежные сервисы часто сталкиваются с двойными списаниями при сбоях HTTP-запросов по таймауту. Автоматические политики повторов, настроенные без учета архитектурных особенностей, могут приводить к созданию нескольких транзакций по одному действию пользователя.
Распространенные методы борьбы с проблемой, такие как отключение повторов для POST-запросов или использование заголовка Idempotency-Key, не всегда эффективны. Отключение retry оставляет систему в неопределенности, а дедупликация через Redis может терять данные при сбоях.
Автор подчеркивает, что идемпотентность должна быть свойством контракта между всеми участниками платежного конвейера. Этот контракт обязан сохраняться на всех этапах: от кнопки в приложении до проводки в главной книге и формирования клиринговых файлов.
Механизмы повторных запросов являются лишь тактическим инструментом, который работает корректно только при наличии полноценного архитектурного контракта. Без него автоматические retry не повышают устойчивость системы, а лишь ускоряют её выход из строя.
