Should this call be synchronous or asynchronous?
“How do you decide whether an interaction between two services should be a synchronous request or an asynchronous message? Give the failure modes of both.”
What this tests
- Decision criteria: does the caller need the result now, is the work retryable, fan-out, burstiness
- Failure modes of sync (cascading latency, timeouts) and async (invisible backlog, stale state, duplicates)
- The hybrid: sync command, async consequences
- Whether "decoupling" is used as a reason or a slogan
Answers by level
Read the beginner answer first and notice what is missing.
Synchronous when the caller needs the result to continue: authorising a payment before confirming an order, validating an address before saving it, anything the user is waiting to see. Asynchronous when the caller only needs the work to happen eventually and the work is retryable: sending the confirmation email, updating a search index, notifying analytics; also when one fact fans out to many consumers, or when producer bursts exceed what the consumer can absorb in real time.
Sync fails by cascading: the callee's p99 becomes the caller's, a slow dependency exhausts the caller's threads or connections, and a chain of four services multiplies the timeouts and the unavailability. Async fails quietly: the backlog grows unseen, state the user sees is stale (the order is placed but inventory has not decremented), messages are delivered twice or out of order, and a consumer bug is discovered hours later. Both need instrumentation, but async needs queue depth and oldest-message age as first-class alerts.
Most real flows are hybrid: a synchronous command that validates and durably records (place order, respond 201), then asynchronous consequences via an event. The user gets a fast, consistent answer about the thing they asked for, and everything downstream is decoupled.
Green flags · Red flags
- Decides by whether the caller needs the result, retryability, fan-out and burstiness
- Names cascading latency and thread exhaustion for sync
- Names invisible backlog, staleness and duplicates for async
- Proposes the sync-command / async-consequences hybrid
- Alerts on oldest-message age, not just depth
- "Always go async; synchronous calls are an anti-pattern in microservices."
- Uses "decoupling" without saying what fails differently
- Makes a user-facing validation asynchronous
- Does not mention timeouts or idempotency for whichever side is chosen