Cached Result Replay¶
Procedure — instantiates Idempotent Operation Design
Returns the original completion result to duplicate attempts so callers receive a stable answer instead of causing new execution.
Sometimes the danger of a repeat is not a duplicated effect but a lost answer: the operation ran fine the first time, but the caller never received the reply and now cannot tell whether it happened. Cached Result Replay resolves this from the response side. On the first attempt it executes the operation and stores the outcome under the operation's key; on any later attempt carrying the same key, it skips execution entirely and returns the stored result verbatim. Its defining move is that a duplicate produces no new work — only a re-served answer. Where a ledger records what happened and an upsert converges the state, this procedure is specifically about giving the caller back the original result, so a retried request reads as a stable confirmation rather than a fresh action. It consumes the stored record; its own contribution is the policy of replaying it.
Example¶
A traveler books a flight through a mobile app. She taps "Confirm booking"; the airline's system creates a reservation, assigns a booking reference (PNR) and seat, and starts sending the response — then her connection drops. The app shows a spinner, then a timeout. She has no way to know whether she has a seat or not, and taps "Confirm booking" again. Because the confirm endpoint replays cached results, the second tap carries the same idempotency key the app generated for that booking intent. The system finds a completed booking already stored under that key and returns the same PNR, the same seat, the same confirmation — without creating a second reservation or charging a second time. The traveler sees one booking, exactly the one she made, no matter how many times uncertainty made her retry. The cached answer stays available through the whole window in which a retry is plausible; only after that does it expire.
How it works¶
The procedure turns on caching an outcome against a key and short-circuiting on replay:
- Key the request. The caller supplies (or the boundary derives) an idempotency key that identifies the intended operation, stable across retries of the same intent.
- First attempt: execute and store. Run the operation, then persist its result — success payload or the specific error — against that key.
- Later attempt: replay. If the key already has a stored result, return it verbatim and do not re-execute.
- Expire on a window. Keep each stored result available only for as long as a duplicate is realistically possible, then let it age out.
The distinguishing feature is the skip: replay is a read, never a re-run.
Tuning parameters¶
- Replay fidelity — return the exact original response versus a lighter "already completed" acknowledgement. Exact replay is transparent to the caller but requires storing the full result; an acknowledgement is cheap but forces the caller to fetch state separately.
- Key derivation — caller-supplied idempotency key versus a content hash the boundary computes. A supplied key distinguishes a deliberate retry from a coincidentally identical new request; a content hash needs no cooperation but cannot tell them apart.
- Retry window length — how long a result stays replayable. A long window covers slow clients and delayed retries but holds results (and any sensitive data in them) longer; a short window is lean but lets a late duplicate re-execute.
- In-flight handling — what a duplicate arriving while the first is still running receives: wait, a "processing" status, or a rejection. This closes the gap the store-after-completion timing would otherwise leave open.
When it helps, and when it misleads¶
Its strength is that it makes an uncertain caller safe to retry without any change to the operation itself: repeat the request, get the original answer, cause nothing new. It is, in effect, memoization applied to an effectful operation — caching the outcome so a repeated call is a lookup, not a recomputation.[n1] That is what turns "I don't know if it worked" into "here is exactly what happened."
It misleads when the cached result outlives its truth or its window. If the underlying state can change after the result is stored, replaying a stale answer can mislead the caller about the current situation — replay is faithful to the original outcome, which is not always the present one. And a retry window set shorter than real client behavior lets a late duplicate slip past the cache and execute again, resurrecting the double-effect the procedure exists to prevent. The classic misuse is caching the response while the side effects are not covered by the same key, so the caller gets one confirmation while a second email or downstream call fires anyway. The guarding discipline is to size the window to observed retry behavior, mark replayed responses as replays where the caller needs to know, and ensure the key that gates the replay also gates every material effect.
How it implements the components¶
Cached Result Replay fills the response-side subset of the archetype — the components that govern what a duplicate caller receives:
result_replay_policy— its signature: the rule that a recognized duplicate is answered with the stored original result rather than a re-execution.idempotency_key— the key under which each outcome is cached and later retrieved, telling a retry of the same intent from a genuinely new request.retry_window— the retention span over which a stored result stays replayable before it expires.
It serves a stored answer but does not build the store: it does not maintain the operation-identity record or detect duplicates across the system (operation_identity, duplicate_detection, completion_record, audit_trail — that is Deduplication Table or Ledger, its nearest twin, which holds the recorded result while this procedure is the policy that replays it). It also does not converge the underlying state (target_state — Upsert or Set Operation) or suppress outbound effects (side_effect_guard — Outbox Deduplication).
Related¶
- Instantiates: Idempotent Operation Design — it makes an uncertain retry safe by returning the original result instead of re-executing.
- Consumes: Deduplication Table or Ledger — it reads the stored outcome the ledger persists, and replays it.
- Sibling mechanisms: Deduplication Table or Ledger · Upsert or Set Operation · Outbox Deduplication · Checklist Confirmation · Duplicate-Safe Payment Operation · Idempotent API · Safe Retry Protocol · Event Replay Deduplication
Editorial Notes¶
Form Classification¶
Form family: Control, Automation & Runtime
Rationale: Returns the original completion result to duplicate attempts so callers receive a stable answer instead of causing new execution, making its operative form a live operational control that automatically routes, enforces, adapts, or responds during execution.
Independent corroboration: The frozen evidence defines Cached Result Replay as 'Returns the original completion result to duplicate attempts so callers receive a stable answer instead of causing new execution', so its operative form is Control, Automation & Runtime.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Single lineage
Present-day reach: Specialized
Rationale: Idempotent API and distributed-systems practice stores an operation's first result and replays it for duplicate request identities without re-executing effects.
Review outcome: Independent reviewer agreement; high confidence.
Notes¶
Cached Result Replay and Idempotent API are easily confused: the API is the whole interface guarantee at a request boundary, whereas this procedure is the narrower store-and-return-the-original step that can live inside an API, a message handler, or a batch job. An idempotent API typically uses result replay; result replay does not require an API.
[n1] Memoization — caching a computation's result so a later call with the same inputs returns the stored value instead of recomputing. Cached Result Replay applies the same idea to an effectful operation: the cache key is the operation's identity, and the payoff is not just speed but the prevention of a second execution. ↩