Design Payments

This lands as the level-gated stretch in the system-design round, usually phrased as a wallet with holds and payouts. It is correctness-first, and throughput is the easy part. A payments system that double-charges a card, pays a host twice, or cannot say where a number came from has failed at the one thing it exists to do. So the headline requirement is correctness under retries and failures. The scale is modest; the consequences of a single wrong write are not.

Name the hard part up front, because the interviewer will steer at it. The network between our service and the banks on either side is unreliable, and any step can time out without telling us whether it happened. We send a charge to the processor, the call times out, and now we do not know if the card was charged. Retry blindly and the guest pays twice; skip the retry and the booking has no money behind it. Every money movement has to be safe to repeat, and the books have to balance to the cent even when half the steps in a workflow had to run two or three times. We build the correct ledger first, then make every operation on it idempotent.

The Airbnb angle

Payments is the senior-and-up stretch, and it tests product correctness over infrastructure trivia. Do you reach for double-entry bookkeeping and idempotency keys on your own, the way someone who has actually moved money does? Airbnb has written publicly about rebuilding its payment orchestration around a framework it calls Orpheus, where every workflow is a directed acyclic graph of retryable idempotent steps. You're not expected to reproduce it, but reach for the same primitives, a balanced ledger and an idempotency key on every step, and the depth speaks for itself. Open with correctness, then go hunting for the retry that double-charges, because the interviewer will.