How do you decide whether two backend capabilities communicate through a synchronous API call or asynchronous messaging?

Synchronous vs asynchronous service communication

Selects synchronous calls, asynchronous messaging, or a deliberate combination based on user feedback, coupling, latency, durability, and failure behavior.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I would use a synchronous call when the caller needs an immediate result to continue, such as validating credentials or reading current product data. I would use asynchronous messaging when work is long-running, bursty, fan-out oriented, or can finish after the user receives an acknowledgement. An asynchronous API can durably record the request, return an accepted response with an operation id, and let a worker update status. A queue decouples time and absorbs bursts, but it also introduces duplicate delivery, delayed completion, retries, and operational state that the design must handle.

Full answer below

Practice focus

Communication semantics, latency, temporal coupling, queues, durable intent, retries, idempotency, ordering, backpressure, and user-visible status.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
Communication style changes both the user experience and the failure model. The useful choice comes from when the result is needed and what the system must do when the other component is slow or unavailable.
I would use a synchronous call when the caller needs an immediate result to continue, such as validating credentials or reading current product data. I would use asynchronous messaging when work is long-running, bursty, fan-out oriented, or can finish after the user receives an acknowledgement. An asynchronous API can durably record the request, return an accepted response with an operation id, and let a worker update status. A queue decouples time and absorbs bursts, but it also introduces duplicate delivery, delayed completion, retries, and operational state that the design must handle.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
Many flows benefit from both styles. The request path can synchronously validate authorization and business invariants, commit the intended state, and publish work through an outbox for asynchronous processing. Consumers need idempotency, bounded retries, dead-letter handling, correlation, and an ordering rule where order matters. The contract also needs to distinguish commands, which request an action, from events, which report a fact. Users need a truthful pending, failed, or completed state instead of an optimistic success message before durable work exists.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
I would assign a latency and failure budget to each boundary. Synchronous dependency chains multiply tail latency and availability risk, so I would keep critical paths short, propagate cancellation, set timeouts, and degrade deliberately. For asynchronous paths I would monitor queue age, throughput, retry volume, poison messages, and end-to-end completion time; queue depth alone does not reveal user delay. I would avoid messaging where a local transaction or direct call is simpler, and avoid promising exactly-once delivery. Durable state, idempotent effects, and reconciliation provide a more honest reliability model.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Using a queue only to make an endpoint look faster while hiding failure from the user.
Building long synchronous call chains with no timeout budget.
Publishing a message separately from the database commit.
Ignoring duplicate delivery, ordering, and poison messages.

Red flagsCandidateSigns the approach is fragileSignals that an interviewer may treat as risky.Open details

Details

The communication choice is based on fashion rather than result timing or failure needs.
An accepted request has no durable status or recovery path.
Retries can repeat a business effect such as a charge or email.
No metric connects broker health to the user-visible completion time.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

How would you make the database update and message publication reliable?
What happens when a consumer processes the same message twice?
When would you replace an asynchronous flow with a direct call?

Continue the section