intermediate 2 min answer Multiple choice

Order service must notify inventory, billing and notifications when an order is placed. Synchronous calls or events? Justify.

couplingmessagingdesign
Pick one
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.