Asynchronous Request/Reply Pattern
Asynchronous Request/Reply: start from the problem
See the responsibilities
Generating a large report takes longer than an ordinary request should wait. The service can acknowledge accepted work and let the client inspect its result later, provided that acceptance has a clear persistence and access contract.
This is a workflow and resilience pattern lesson. Follow the responsibilities, inspect the small JavaScript example and compare the design choices. The example is local teaching code; its boundary is explained before you apply the idea to a real service.
What you’ll learn
- Explain the problem Asynchronous Request/Reply addresses and the roles involved.
- Follow the example and distinguish this pattern from nearby alternatives.
- Choose when the benefit justifies the extra responsibilities and testing.
How the responsibilities work
Asynchronous Request/Reply returns an operation identity instead of pretending the business work has finished. A status resource or supported callback exposes pending, completed and failed outcomes. The identity connects retries and later observations to one intended job.
The local example returns accepted and pending, then records completion. It does not enqueue durable work or run a background worker. Production acceptance must follow the required durable boundary and protect status and result access.
Follow a small example
Read the JavaScript from top to bottom and compare the expected output. The values are chosen to make this pattern’s responsibility visible. This example runs in one local execution context; it does not create remote services, durable storage or production access controls.
JavaScript · local teaching example
const jobs = new Map();
function accept(id) {
if (!jobs.has(id)) jobs.set(id, {status: 'pending'});
return {accepted: true, id};
}
console.log(accept('J1').accepted);
console.log(jobs.get('J1').status);
jobs.set('J1', {status: 'completed', result: 'report.csv'});
console.log(jobs.get('J1').status);Expected output
true
pending
completedChoose a design and inspect the consequence
Compare the design choices
Compare the visible consequences. With JavaScript enabled, choose an option in each scenario to assemble your decision record.
This is an exploratory design exercise. It does not run infrastructure, measure capacity or replace the lesson’s quiz.
Apply the pattern to two situations. Select one option in each situation to build a decision record. Every option and its consequence stays visible, and you can change your choices.
When it helps—and what it costs
Use it when a useful operation outlasts a synchronous waiting budget and the user can follow an operation through explicit progress and results.
Lost submission responses can trigger duplicates; coordinate retry identity with durable admission. Status endpoints need authorization, retention and a polling budget. Expired or unknown jobs must not be reported as successful, and callbacks can be lost or repeated.
Distinguish the neighbouring patterns
A queue carries work to processors. Asynchronous Request/Reply defines the client-facing operation contract. Saga records a multi-owner business workflow and can expose its progress through such a contract.
Follow accepted jobs and bounded worker work, safe repeat submission, accepted uploads versus ready media to compare the specific responsibility before combining patterns.
For further reading, use Microsoft’s Asynchronous Request/Reply guidance. Compare it with this original example and the guarantee required by your application.
Check your pattern reasoning
Check your pattern reasoning
Compare the pattern boundaries
Name the responsibility before choosing the pattern
For Asynchronous Request/Reply, describe the problem, the participating roles and the observable contract. Use the example as a starting point and test the boundaries identified in the trade-offs. A pattern name alone does not establish correctness or performance.
Return to the design-pattern guide to compare families, or apply the idea alongside accepted uploads versus ready media.
Reaching the recap and completing the quizzes are separate milestones.