Idempotency Store

Overview

Meaning and scope

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. It is more than an in-memory cache when payment safety requires records to survive process restarts, failover, or delayed retries.

Mechanism and operation

Metrics for Idempotency Store should separate first-attempt success, recovered operations, exhausted attempts, duplicate prevention, and added latency. 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. For Idempotency Store, a missing response should remain uncertain until status lookup or reconciliation confirms whether the original operation executed.

Practical payment example

A payment service maintains a durable idempotency store shared across workers to prevent duplicate execution during retries.

Operational checks

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.

Distinctions and limits

The main risks include split-brain writes, stale reads, unavailable lookups, data loss, excessive latency, and capacity exhaustion during retry storms. Manual intervention for Idempotency Store should begin only after automated status checks cannot determine a safe final outcome.

Related reading

Related definitions: Idempotency Record, Idempotency Result Cache.