45. Design a Payment System (Stripe / UPI)
1
The interview prompt2
45.1 What do you ask first?3
45.2 How big is this, really?4
45.3 What are the doors?5
45.4 What do we store?6
45.5 What does the whole system look like?7
45.6 How does idempotency work end to end?8
45.7 How does a double-entry ledger work?9
45.8 How does reconciliation work?10
45.9 How do callbacks and webhooks work?11
45.10 How do you keep it consistent?12
45.11 What would you say in the last five minutes?13
Score yourself14
Variations to practise15
Sources16
Code lab45. Design a Payment System (Stripe / UPI)
Score yourself
3 min read+10 XP
Score yourself
Give yourself 0, 1 or 2 points per row.
| Area | 0 points | 1 point | 2 points |
|---|---|---|---|
| Requirements | Started drawing | Pay and refund | Exactly-once effect, unknown outcomes, auditability and card data agreed |
| Estimates | None | Numbers, not used later | Moderate throughput, ledger growth and retention drove SQL, sharding and partitioning |
| API and data | Skipped | API only | Idempotency keys, integer amounts, intents, attempts, balanced ledger lines, outbox |
| High-level design | Call the bank, update a balance | Engine + DB | Intent → attempt → ledger + outbox, callbacks, status checks, reconciliation walked |
| Deep dive | Hand-waved | One topic | Idempotency at every hop, double-entry, pending + reconciliation, webhooks or consistency done properly |
| Trade-offs | None named | Named when asked | Raised unprompted (pending vs guessing, strong vs eventual, hot accounts) |
| Communication | Long silences | Mostly clear | Thought out loud, checked in, managed time |
12 to 14: strong hire signal. 8 to 11: solid, polish the weak rows. Under 8: redo the round in a week, timer on.
The bar: fresher vs SDE-2
| Fresher | SDE-2 | |
|---|---|---|
| Double charges | "Check if already paid" | Idempotency keys at every hop, unique ledger transaction IDs |
| Money records | Balance column | Double-entry, append-only, derived balances, integer amounts |
| Unknown outcomes | Retry or fail | Pending state, status checks, callbacks, reconciliation |
| Notifications | Callback URL | Signed, retried, de-duplicated webhooks; server proof over browser redirects |
| Consistency | One big transaction | State + ledger + outbox together; eventual elsewhere; sagas across shards |
Common mistakes
- Treating a timeout as a failure (or as a success).
- A mutable balance column with no ledger behind it.
- Floating-point money.
- Trusting the browser redirect as proof of payment.
- Editing or deleting past ledger entries instead of reversing them.
- No reconciliation, so lost callbacks are never noticed.
Quick check
Five questions on this chapter. Pick an answer, then check it.
quiz