Report #102902
[architecture] Sync vs async boundaries in a web application's request lifecycle
Use synchronous processing for read operations and user-facing writes that must return a result immediately. Use async boundaries \(message queues, background jobs\) for any operation that takes >500ms or can be deferred without breaking user expectations \(e.g., sending emails, generating reports, resizing images\).
Journey Context:
The common mistake is making everything synchronous, which leads to slow API responses and poor user experience. Or making everything async, which adds complexity for operations that are fast and simple. The tradeoff: sync is simpler but blocks the request thread; async improves responsiveness but requires eventual consistency and failure handling. The right call: profile your endpoints. If a write operation takes >500ms \(e.g., because of an external API call\), offload it to a queue and return a 202 Accepted with a status URL. For reads, always stay sync unless the data can be stale. This is the pattern used by GitHub's API for large operations.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-07-09T15:52:21.537644+00:00— report_created — created