Payment / Wallet System

How this problem is worked

Ten stages, from the questions you would ask an interviewer to the trade-offs you would defend. Each asks one question, and the simulator runs the architecture you draw against the requirements you wrote.

1. 01ClarificationsWhat would you ask before drawing a single box?
2. 02Functional reqsWhat must this system actually do?
3. 03Non-functionalWhat must it promise about speed, uptime and correctness?
4. 04Capacity estimationHow much load and data does this have to hold?
5. 05API designWhat does the outside world call, and what comes back?
6. 06Data modelWhat gets stored, and what is it looked up by?
7. 07Use-case breakdownHow does each requirement actually get served?
8. 08High-level designWhich components handle a request, and in what order?
9. 09Deep divesWhich part breaks first, and what do you do about it?
10. 10Trade-offsWhat did this design cost, and what breaks at 10×?

Primary sources for this problem

• Brandur — Implementing Stripe-like Idempotency Keys in Postgres
• Stripe — Designing robust APIs with idempotency
• Square — Books: an immutable double-entry accounting database
• Monzo — Speeding up balance reads (ledger)
• Uber — Engineering Uber's Next-Gen Payments Platform (Gulfstream)
• Airbnb — Avoiding double payments (Orpheus)
• Garcia-Molina & Salem — Sagas (1987)
• Debezium — Outbox pattern