Idempotency Result Cache

Overview

An Idempotency Result Cache stores the response or outcome associated with a completed idempotent operation so later retries can receive the same established result. It differs from the idempotency record when the record is the authoritative state and the cache is only an optimization or result-retrieval layer.

The main risks include returning stale or mismatched results, cache eviction before the idempotency window ends, inconsistent errors, and exposure of sensitive response data. The cached result may include success, validation failure, or a selected server error according to the API contract. 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. Idempotency Result Cache is closely connected to Idempotency Record, Idempotency Store, and Idempotent Request. The Idempotency Result Cache implementation should bound attempts, preserve the original operation identity, and stop before retries amplify a dependency failure.

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.