An order service must notify inventory, billing, shipping and analytics when an order is placed. Synchronous calls or events? Justify your choice per consumer.

What the interviewer is testing

Whether you apply the decision per interaction rather than adopting one style globally.

The framing that matters

Synchronous calls make the caller's availability the product of every callee's. Four synchronous dependencies at 99.9% put a ceiling of about 99.6% on order placement. They also make latency additive and put the caller in the position of deciding what to do when a callee fails mid-sequence.

Asynchronous events decouple availability and latency, but move the system to eventual consistency and make the flow harder to observe.

The correct question is: does the user's action succeed or fail based on this consumer's response?

Per consumer

Inventory — synchronous, usually. If you cannot reserve stock, the order should not be accepted; discovering this asynchronously means cancelling an order the customer thinks is placed. The alternative is deliberate overselling with a compensation policy, which is a legitimate business choice for some catalogues and must be made by the business rather than assumed.

Billing — depends on the model. Authorising a card is synchronous, because a declined card must fail the order. Capturing the payment is asynchronous, because it happens at fulfilment. Splitting authorisation from capture is the standard answer and shows familiarity with how payments actually work.

Shipping — asynchronous. Nothing about the order's validity depends on the warehouse responding within the request. A queue absorbs warehouse downtime entirely.

Analytics — asynchronous, always. An analytics outage must never be able to fail an order, and if it can, that is a serious design defect rather than a minor one.

The resulting shape

Order placement synchronously reserves inventory and authorises payment, commits, and emits an OrderPlaced event via a transactional outbox. Shipping and analytics consume it. Two synchronous dependencies instead of four, and the two that remain are the ones that genuinely gate the business outcome.

What a strong answer adds

• The outbox, so the event is atomic with the order — otherwise the async path has a dual-write bug.
• Compensation for the synchronous pair: if payment authorisation fails after inventory is reserved, the reservation must be released. That is a small saga.
• Recognition that "async is more available" is only true if the queue is more available than the consumer, which requires the queue to be genuinely independent.