Idempotency Result Cache

Overview

Meaning and scope

An Idempotency Result Cache stores the response or outcome associated with a completed idempotent operation so later retries can receive the same established result. The cached result may include success, validation failure, or a selected server error according to the API contract. It differs from the idempotency record when the record is the authoritative state and the cache is only an optimization or result-retrieval layer.

Mechanism and operation

The Idempotency Result Cache policy should define which failures are retryable, how long the decision remains valid, and how duplicate effects are prevented. In production, teams should define ownership and apply authoritative record linkage, immutable result serialization, expiration alignment, request fingerprint checks, cache consistency, and secure access. Manual intervention for Idempotency Result Cache should begin only after automated status checks cannot determine a safe final outcome. Useful measures include result-cache hit rate, stale-result incidents, lookup latency, eviction-before-expiry count, and response consistency rate. The Idempotency Result Cache implementation should bound attempts, preserve the original operation identity, and stop before retries amplify a dependency failure.

Practical payment example

Two workers submit the same payout request with one idempotency key. The provider returns the original result on retry, while the merchant tracks the key’s retention window and request-parameter consistency.

Operational checks

Metrics for Idempotency Result Cache should separate first-attempt success, recovered operations, exhausted attempts, duplicate prevention, and added latency. A Idempotency Result Cache decision should use documented method semantics and provider error classes rather than message text alone. Configuration changes to Idempotency Result Cache should be versioned and tested under burst, timeout, dependency failure, and restart conditions.

Distinctions and limits

The main risks include returning stale or mismatched results, cache eviction before the idempotency window ends, inconsistent errors, and exposure of sensitive response data.

Related reading

Related definitions: Idempotency Record, Idempotency Store.