Asynchronous Request-Response
A request-response workflow where processing completes after the initiating call has returned.
Jul 11, 2026
Asynchronous request-response separates accepting work from completing it. The requester submits an operation, receives an acknowledgement or operation identifier, and obtains the result later through polling, a webhook, or a message.
A typical lifecycle is:
- The requester creates a unique Correlation ID or operation ID.
- The receiver validates and durably records the request.
- The receiver acknowledges acceptance without waiting for the work to finish.
- A worker processes the operation.
- The result is stored before or while a completion notification is delivered.
- The requester matches the result to the pending operation and records completion.
Durability Boundary
The important design question is not which process receives the response. It is where the pending operation and result are stored.
If request context exists only in one service instance, a crash, deployment, or autoscaling event can lose the ability to finish the workflow. Persisting the operation state allows any healthy instance to resume processing. This also makes retries and reconciliation possible.
Instance affinity is justified only when the final resource is genuinely process-local, such as a WebSocket connection. Even then, durable business state should remain independent of that connection. A connection registry or gateway can route the final notification to the connected node.
Failure Model
An asynchronous workflow must define behavior for:
- a request accepted but not processed;
- work completed but the response not delivered;
- duplicate requests or responses;
- responses arriving after a timeout;
- the requester restarting while work is in flight;
- the provider remaining unavailable.
Delivery acknowledgements do not prove that business processing happened exactly once. Consumers should use idempotency keys or conditional state transitions, persist progress, and reconcile operations that remain pending beyond an expected deadline.
Delivery Choices
Polling vs Webhooks compares two HTTP delivery models. Message brokers can carry both requests and responses; RabbitMQ Reply Queues describes RabbitMQ-specific options.