Order service must notify inventory, billing and notifications when an order is placed. Synchronous calls or events? Justify.
Show the full answer Hide the answer
What the interviewer is testing
Whether you decide per dependency based on whether the outcome must be known now, rather than choosing one style for everything.
The distinguishing question
Does the order's success depend on this succeeding?
Inventory: yes. If stock cannot be allocated, the order should not be confirmed. The caller needs the answer before responding to the customer, so this is synchronous — or, better, a synchronous reservation with the commitment happening later in a saga.
Billing: usually not at this moment. Payment authorisation typically happens before order placement; the billing record can be created asynchronously. If it must be synchronous, that is a domain requirement worth stating explicitly rather than assuming.
Notifications: no. An email failing must never fail an order, and the customer would rather have the order than the confirmation email.
Why not all synchronous
Three synchronous calls means the order service's availability is the product of four systems, its latency is the sum, and a slow notification service — the least critical of the three — can exhaust connection pools and take down order placement entirely.
Why not all asynchronous
Inventory has a global invariant. Publishing an event and hoping is how a system oversells, and the customer is told their order succeeded before anyone knew whether it could.
The design
Synchronous reservation against inventory, then publish an OrderPlaced event. Billing, notifications
and anything else added later subscribe. New consumers require no change to the order service, which
is the durable benefit.
Publish through an outbox, so the state change and the event commit atomically rather than as a dual write.
What a strong answer adds
Naming the coupling that events do not remove: temporal coupling goes, semantic coupling stays.
Every consumer still depends on what OrderPlaced means, so its schema and semantics need a contract
and a compatibility policy regardless of the transport.
Common weak answers
All events, for decoupling, without addressing the inventory invariant. All synchronous, for simplicity.