Sync vs Async Between Services

The Two Modes

 SYNCHRONOUS (request/response):
   caller BLOCKS for the answer:
   [orders]──GET stock?──►[inventory]──reply──►[orders]
   + simple mental model, immediate answers
   − temporal coupling: both must be UP; latency chains;
     failure propagates along the call path

 ASYNCHRONOUS (events/messages):
   fire facts/commands; react when ready:
   [orders]──OrderPlaced──►[bus]──►[inventory] (whenever)
   + decoupled in time and failure; buffering built-in
   − eventual consistency; harder debugging; idempotency duty

 EVERY service-to-service edge is one of these.
 the choice shapes latency, availability, AND consistency.

The Decision Frame

 ask per interaction, in order:

 1. does the CALLER need the ANSWER to proceed?
    yes → sync is honest (checkout needs payment result)
    no  → async candidate ✓

 2. would the callee being DOWN be acceptable briefly?
    yes → async (work waits)
    no  → sync with breakers/fallbacks... or redesign

 3. is this a FACT others react to vs a QUESTION to one party?
    fact → event (pub-sub semantics)
    question → request/response of some flavor

 anti-patterns on both ends:
 ✗ sync CHAINS: A→B→C→D sequential calls = latency sum ×
   availability product. depth >2-3 smells redesign.
 ✗ async where UX demands NOW ("login via queue" absurdity)

The Hybrid Reality

 real flows mix modes deliberately:

 CHECKOUT:
   sync core:  [cart]→[payment-auth]→[stock-hold]  (user waits)
   async tail: OrderPlaced ──► email, analytics, loyalty,
                               supplier-notification...

 pattern name: SYNC SPINE + ASYNC RIBS.
 keep the synchronous chain SHORT and critical-only;
 everything else rides events behind the response.

 latency budgeting falls out naturally:
 spine ≤ user tolerance; ribs cost zero perceived time.

Interaction	Mode	Why
Payment authorization	sync	answer gates the flow
Sending receipt	async	nobody waits for SMTP
Stock reservation	sync	must know before confirm
Restock notification	async	fact-broadcast
Fraud scoring at checkout	sync (tight) or pre-computed	depends on risk design

Consequences Worth Naming

 choosing sync means ALSO adopting:
 timeouts, retries-with-idempotency, circuit breakers,
 bulkheads, fallbacks (the whole resilience kit).

 choosing async means ALSO adopting:
 idempotent consumers, outbox/dual-write fixes,
 lag monitoring, eventual-consistency UX.

 neither mode is "less work" — they buy DIFFERENT work.
 the mistake is choosing by diagram aesthetics instead
 of by coupling consequences.

Interview Framing

“Should orders call inventory synchronously?” scored shape: interrogate the requirement first (does checkout NEED live stock?), present sync-spine+async-ribs decomposition for the flow, list the adopted-consequences kit for whichever mode chosen, flag sync-chain-depth as a smell. This question grades whether you treat interaction mode as an ARCHITECTURAL decision with bills attached — not a default you never examined.