Проблема фантомной записи: почему ваша реализация идемпотентности незаметно теряет данные

• Статья описывает Phantom Write Problem: проверки идемпотентности проходят, но данные всё равно повреждаются при реальной конкурентности, crash-recovery и повторах.
• Выделены четыре режима отказа: истечение TTL для ключей, частичное выполнение с зависшим IN_PROGRESS, TOCTOU-гонка при конкурентной проверке и потеря идемпотентности на границах API/Kafka/downstream.
• Рекомендуемый паттерн Idempotency Barrier: хранить ключи в БД, не завязывать корректность на TTL, выполнять бизнес-запись и смену статуса в одной транзакции, атомарно захватывать ключ через INSERT ... ON CONFLICT / SELECT ... FOR UPDATE и прокидывать correlation/idempotency key через системные границы.
• Для финансовых и order-processing систем Redis-only и локальная API-дедупликация недостаточны; каждый downstream-потребитель должен иметь собственный барьер идемпотентности.
• Для наблюдаемости предлагаются метрики idempotency.hit.rate, idempotency.stale.reclaim.count и idempotency.status.distribution.