Art of Codeartofcode
Lesson 3 of 16

45. Design a Payment System (Stripe / UPI)

1
The interview prompt
2
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 yourself
14
Variations to practise
15
Sources
16
Code lab
45. Design a Payment System (Stripe / UPI)

45.2 How big is this, really?

3 min read+10 XP

Step 2: Estimates (5 minutes)

Assume 3 ledger lines per capture, about 200 bytes per ledger line, about 50 million payments a day, and records kept for many years (as regulators require).

WhatWorkingResult
Peak paymentsgiven2,000 a second
Ledger lines at peak2,000 × 36,000 a second
Ledger growth50 million × 3 × 200 bytes≈ 30 GB a day ≈ 11 TB a year
For perspective: UPI20 billion a month ÷ 2.6 million seconds≈ 7,700 a second on average, nationwide

What the numbers say, out loud:

  • "Throughput is moderate; a well-sharded relational database handles thousands of transactional writes a second."
  • "Correctness, not speed, drives the design: transactions, idempotency, append-only records."
  • "Data lives for years: partition the ledger by time, archive older partitions, keep them queryable for audits."

Interviewer pushback:

  • "NoSQL for scale?" → Money needs multi-row transactions (all lines of a ledger transaction together) and constraints. A relational database, sharded by merchant or account, fits; Chapter 8's guidance applies.

Memory code: "Moderate speed, absolute correctness, years of history."