A checkout flow makes 9 synchronous calls: inventory, pricing, tax, fraud, payment, loyalty, shipping, notification and analytics. What would you change?

What the interviewer is testing

Whether you can classify dependencies by whether the outcome must be known now.

The availability problem

Nine serial synchronous dependencies. At 99.9% each, the ceiling is about 99.1% — roughly 79 hours a year — before checkout's own reliability. Latency is the sum of nine calls.

Both are unacceptable for the revenue path, and no amount of effort inside checkout improves either.

The classification

Must be synchronous — the outcome changes whether the order proceeds:

Inventory (a global invariant; overselling is unrecoverable). Pricing and tax (the customer must be charged a correct, legally-required amount). Fraud (blocking is the purpose). Payment (the outcome is the transaction).

Should be asynchronous — the order is valid regardless:

Loyalty points. Notification. Analytics. Shipping arrangement, in most models, since it happens after the order is confirmed.

That is four hard dependencies rather than nine, taking the ceiling to about 99.6% and cutting latency by more than half.

What to do with the asynchronous four

Publish an OrderPlaced event through a transactional outbox, so the event and the order commit atomically rather than as a dual write. Consumers handle loyalty, notification, analytics and fulfilment independently, and a failure there is a delayed side effect rather than a lost order.

What to do with the remaining four

Timeouts derived from measured latency, not defaults, with bulkheads so one slow dependency cannot exhaust the shared pool.

A degraded mode for fraud, agreed with risk: if the fraud service is unavailable, accept below a value threshold and queue for review, or decline. A decision made in advance, not by the code's default.

Idempotency keys on payment and inventory, generated per order.

What a strong answer adds

Questioning tax and pricing specifically. These can frequently be precomputed or cached — tax rules change rarely, and a cached rate with periodic refresh removes a synchronous call from the revenue path entirely. That would take it to two genuinely hard dependencies.

Common weak answers

Parallelising the nine calls, which improves latency and leaves the availability multiplication unchanged. Making everything asynchronous, which oversells inventory.