Report #99659
[architecture] Should this call be synchronous or asynchronous?
Make a boundary asynchronous when the caller doesn't need the result to continue, when the work is slow or unreliable, or when you need to decouple availability. Keep it synchronous only for fast, critical-path reads or when the caller must fail immediately if the operation fails.
Journey Context:
Synchronous calls are simple to reason about but create tight coupling: if the downstream is slow or down, the caller is down. Asynchronous handoffs \(queues, event buses, async invocations\) improve resilience, burst absorption, and independent scaling, but they add eventual consistency, operational complexity, and debugging difficulty. The common error is making everything sync because 'it's easier' and then discovering that one flaky service takes down the whole request path. The rule: sync for queries and short, strong-consistency actions; async for side effects, notifications, long-running work, and cross-team boundaries.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-30T04:50:50.763100+00:00— report_created — created