Synchronous vs Asynchronous Processing

In synchronous processing, the caller waits while the callee performs enough work to return a final result. HTTP request-response is commonly used this way: the connection remains part of the operation's control path until success, failure, or timeout.

In asynchronous processing, the system durably accepts work, returns control before completion, and processes it later. A queue is common but not required; callbacks, polling, streams, and workflow engines can carry the eventual result. The initial response confirms only the boundary it actually crossed.

This is not “real-time vs background” or “HTTP vs messaging.” A producer may synchronously wait for a broker's publish confirmation and still have asynchronous business processing. Name each acknowledgment precisely: request received, message persisted, work started, or business outcome completed.

The synchronous order handler validates the request, reserves inventory, authorizes payment, writes the order, and only then returns 201 Created. The client gets a clear final answer and errors can propagate directly. Tracing is linear because every span belongs to one active request.

The cost is temporal coupling: inventory and payment must both be available and fast inside the caller's deadline. If the API allows 2 seconds, it cannot safely give two dependencies 2 seconds each; each hop needs a smaller budget that leaves time for local work and the response. Unbounded retries multiply load and can turn one slow dependency into a cascading failure.

A client timeout creates an ambiguous outcome. Payment may have succeeded just as the connection closed. The client must retry with the same idempotency key, and the server must return the recorded outcome instead of charging again.

The asynchronous API validates enough to admit the request, creates operation ord-42, durably publishes OrderRequested, and returns 202 Accepted with a status URL. RFC 9110 defines 202 as noncommittal: processing is not complete and may still fail. The response therefore must not say “order placed” unless that business promise is already true.

A worker later reserves inventory, authorizes payment, and records SUCCEEDED or a terminal failure. The client polls GET /operations/ord-42, receives a callback, or consumes an event. Queue depth absorbs bursts, but waiting has moved from an HTTP connection into backlog age. Capacity planning must track arrival rate, processing rate, and oldest-message age.

Do not publish a message after committing an unrelated database transaction and assume both happened. A crash between those writes can create an order with no event. Use a transactional outbox when database state and message publication must become visible together.

For ord-42, the synchronous client stays connected across API → inventory → payment → database. The critical-path latency is approximately the sum of serialized work plus network overhead; parallel independent calls can reduce elapsed time but complicate cancellation and partial failure.

The asynchronous client waits only through validation, operation creation, and durable enqueue. Worker time is outside the initial response, so request latency falls while completion latency may rise with queue wait. Reporting only the fast 202 latency hides what the user cares about.

Measure synchronous paths with end-to-end success latency, timeout rate, and dependency budgets. Measure asynchronous paths with admission latency, enqueue failures, queue depth, oldest-message age, processing latency, redelivery count, terminal failure rate, and end-to-end time from acceptance to completion.

Trigger. A worker receives OrderRequested(ord-42), authorizes payment, then crashes before sending its consumer acknowledgment. Symptom: the broker redelivers the unacknowledged message and a second worker attempts another charge. Root mechanism: at-least-once delivery preserves work through consumer failure by allowing redelivery; it does not provide exactly-once business effects.

Recovery. The second worker uses ord-42 as the payment idempotency key. The payment service returns the original authorization, the worker records the order outcome, and only then acknowledges the message. If an effect cannot be made idempotent, store an inbox/deduplication record in the same transaction as the local state change.

Poison messages need bounded attempts and a dead-letter path with ownership, alerting, and replay tooling. Endless immediate requeue creates a hot loop. A dead-letter queue without a recovery process merely hides failed orders.

Reliable publication and reliable consumption are separate. A publisher confirm tells the producer that the broker accepted responsibility according to its configured durability semantics. A consumer acknowledgment tells the broker that the delivered work was processed far enough to remove it. One does not imply the other.

If the publisher loses its connection before receiving a confirm, it cannot know whether the broker accepted the message. Republish may duplicate it; dropping it may lose it. Use a stable message ID and idempotent consumer. Likewise, if a consumer connection closes before acknowledgment, the broker may redeliver.

Ordering is scoped, not universal. Multiple workers, retries, and partitions can reorder events. If OrderCancelled must not run before OrderCreated, route related events through an ordering boundary or attach an aggregate version and reject/defer stale transitions.

Use synchronous processing when the caller needs the final answer before continuing, the work reliably fits a bounded deadline, and immediate errors are actionable—for example, reading a profile or validating a small command.

Use asynchronous processing when work is long-running, bursty, retryable, fan-out heavy, or need not finish before the caller proceeds—for example, video encoding, report generation, and notification delivery. Provide status and cancellation when the user still owns the outcome.

Most production flows are hybrid. Checkout may synchronously validate the cart and establish payment authorization, commit an order, then asynchronously send receipts and analytics. Keep correctness-critical steps inside the acknowledged contract; move side effects only when delayed or failed completion is acceptable and visible.