Idempotency Store

Overview

An Idempotency Store is the durable data system used to create, retrieve, update, and expire idempotency records. It supports duplicate suppression across processes, servers, regions, and retries that occur after the original connection ends. Metrics for Idempotency Store should separate first-attempt success, recovered operations, exhausted attempts, duplicate prevention, and added latency.

The main risks include split-brain writes, stale reads, unavailable lookups, data loss, excessive latency, and capacity exhaustion during retry storms. It is more than an in-memory cache when payment safety requires records to survive process restarts, failover, or delayed retries.

In production, teams should define ownership and apply atomic conditional writes, consistent reads, replication policy, encryption, retention jobs, hot-key protection, and disaster recovery. Operational review of Idempotency Store should separate successful recovery from repeated attempts that only increase latency or load.

Useful measures include availability, p95 lookup latency, conditional-write conflict rate, replication lag, and expired-record backlog. Idempotency Store is closely connected to Idempotency Record, Idempotency Result Cache, and Request Deduplication. Manual intervention for Idempotency Store should begin only after automated status checks cannot determine a safe final outcome.

For Idempotency Store, a missing response should remain uncertain until status lookup or reconciliation confirms whether the original operation executed. The Idempotency Store implementation should bound attempts, preserve the original operation identity, and stop before retries amplify a dependency failure.

A Idempotency Store decision should use documented method semantics and provider error classes rather than message text alone. Configuration changes to Idempotency Store should be versioned and tested under burst, timeout, dependency failure, and restart conditions.