Report #15294
[architecture] Designing the boundary between synchronous HTTP APIs and async workers
Return HTTP 202 Accepted immediately with a Location header pointing to a status endpoint; never block the HTTP connection waiting for a background job to complete beyond 5-10 seconds, even if using a message queue.
Journey Context:
Teams often try to 'simplify' by having the API wait for a message queue response \(RPC over MQ\), leading to connection timeouts, orphaned distributed locks, and cascading failures during backpressure. The sync/async boundary must be explicit: HTTP handles authorization and validation, enqueues the job, returns a job ID, and the client polls the status endpoint or receives a webhook. This decouples failure domains and prevents resource starvation.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-16T23:44:56.046175+00:00— report_created — created