Request-Reply Correlation¶
Interaction protocol — instantiates Message-Mediated State Coordination
Turns one-way messaging into a two-way conversation by tagging each request so its eventual reply can be matched back to the caller — within a bounded waiting window.
Request-Reply Correlation layers a question-and-answer conversation on top of a channel that is fundamentally one-way and fire-and-forget. The caller does not hold a connection open; it sends a request carrying two things — a reply-to address and a correlation token — and moves on. When an answer eventually arrives on the reply channel, the caller uses the token to match it back to the request that is still waiting. The idea that makes this its own mechanism, rather than a naked event, is the bounded wait: a reply is only valid if it lands inside a freshness window, so a late answer is treated as a failure rather than quietly accepted long after the caller has given up.
Example¶
A ride-hailing dispatcher needs to place a rider with a driver. It broadcasts a "ride available?" request to the handful of nearby driver apps; each request carries a correlation ID and a reply-to address. The dispatcher does not block — it registers a pending offer and keeps serving other riders. Seconds later, replies trickle back onto the reply channel; the dispatcher matches each to its pending offer by correlation ID and assigns the first "yes."
The freshness window is what makes this safe rather than chaotic. A "yes" that arrives ≈15 seconds late — after the rider has already been matched and the offer expired — is discarded, not honored, because acting on a stale acceptance would double-book a driver. The conversation succeeded or timed out; there is no third state where an ancient reply reanimates a closed request.
How it works¶
The protocol is a small amount of bookkeeping layered over async delivery:
- Stamp and register. Each request carries a correlation token and a reply-to address; the caller records a pending entry keyed by that token instead of waiting on a socket.
- Match on return. Replies arrive asynchronously and are demultiplexed back to their pending request by token — many conversations share one reply channel without confusion.
- Bound the wait. A timer governs each pending entry; if no reply lands inside the window, the entry resolves as a timeout and the pending state is cleaned up rather than leaked.
Tuning parameters¶
- Timeout / freshness window — how long to wait before declaring no-reply. Too short manufactures false failures on a slow-but-fine responder; too long ties up pending state and rider patience. This is the highest-leverage dial.
- Reply-to routing — a dedicated reply queue per caller versus a shared reply channel demultiplexed by token. Dedicated is simpler to reason about; shared scales to many callers.
- On-timeout policy — fail, retry, or fall back to a default. This choice couples tightly to idempotency, since a retry may race the original's late reply.
- Receipt vs. full reply — whether a lightweight acknowledgement ("got it, working") is expected separately from the substantive answer, so a slow responder isn't mistaken for a dead one.
- Pending-state durability — in-memory versus persisted. Persisting lets a caller survive a restart mid-conversation instead of orphaning every open request.
When it helps, and when it misleads¶
Its strength is giving you request/response semantics without synchronous coupling: the caller stays responsive and the responder stays decoupled, yet a specific answer still finds its way back to a specific question. That is exactly the shape countless "ask a service and use the answer" interactions need over a message bus.
Its failure modes cluster around the pending state and the timeout boundary. Pending entries leak and grow if replies never come and nothing expires them. Worse, the timeout path and a genuinely late reply can both fire — the caller gives up and acts, then the stale "yes" lands — so any action on the timeout branch must be idempotent or it double-acts. And a receipt is easily mistaken for a result: "got it" is not "done." The classic misuse is reaching for request-reply where a fire-and-forget event would do, reintroducing the latency and coupling the async substrate was chosen to avoid.[n1] The discipline is to bound every wait, expire pending state aggressively, and make the timeout branch idempotent.
How it implements the components¶
reply_and_receipt_policy— defines that a request expects an answer (and optionally an interim receipt), and specifies how that answer is addressed and matched back to the caller.message_freshness_window— the reply timeout: an answer arriving outside the window is stale and discarded rather than acted upon, which is what keeps a closed conversation closed.
It does NOT mint the correlation marker it pairs on (that's Correlation Trace Header, or the key from Retry with Idempotency Key) and does NOT guarantee the underlying delivery (Durable Queue with Acknowledgement) — it is the conversation layer built on top of those.
Related¶
- Instantiates: Message-Mediated State Coordination — it supplies the two-way conversational pattern the archetype needs on top of one-way channels.
- Consumes: Correlation Trace Header provides the marker it matches replies on; Durable Queue with Acknowledgement provides the channel underneath.
- Sibling mechanisms: Correlation Trace Header · Retry with Idempotency Key · Event Choreography · Message Schema Registry · Command Message Handler · Dead-Letter Queue · Actor Mailbox Loop · Backpressure Signal · Bounded Mailbox or Queue · Durable Queue with Acknowledgement · Transactional Outbox/Inbox Relay
Editorial Notes¶
Form Classification¶
Form family: Control, Automation & Runtime
Rationale: Request-Reply Correlation operates as a live operational control that automatically routes, enforces, adapts, or responds during execution because it turns one-way messaging into a two-way conversation by tagging each request so its eventual reply can be matched back to the caller — within a bounded waiting window.
Independent corroboration: The frozen evidence defines Request-Reply Correlation as 'Turns one-way messaging into a two-way conversation by tagging each request so its eventual reply can be matched back to the caller — within a bounded waiting window', 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: Correlation identifiers and bounded request-response matching are messaging and distributed-systems patterns.
Review resolution: Both blind reviewers agree that computer_science is the primary historical origin. Explicit reconciliation of alternate origin disagreement, domain reach disagreement adopts reviewer_a's evidence: Correlation identifiers and bounded request-response matching are messaging and distributed-systems patterns. The selected record uses alternates=none, origin_mode=single_lineage, and domain_reach=specialized; the other review proposed alternates=engineering_design, origin_mode=single_lineage, and domain_reach=multi_domain. The selected combination better preserves the mechanism-specific formative lineages and calibrated scope; broader present-day use is not treated as proof of additional historical origin.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
The dangerous interaction is between the freshness window and retries: once a request times out, the caller may act and a delayed reply may still arrive, so the follow-up must be safe to run twice. In practice this means pairing request-reply with an idempotency discipline (see Retry with Idempotency Key) rather than assuming a timeout cleanly ends the conversation.
[n1] The Correlation Identifier and Request-Reply are named messaging patterns catalogued in Hohpe and Woolf's Enterprise Integration Patterns. The correlation identifier is the token that lets an asynchronous reply be matched to the request that provoked it — the load-bearing idea this mechanism consumes and applies. ↩