Design a payment system like Stripe.

The opening move — minute one

“100M a day is about 1,160 TPS — this isn’t a scale problem, it’s a correctness problem. I’m going to design a small ACID core that can’t lose or duplicate money, and keep everything that tolerates delay async.”

The state machine

CREATED → PROCESSING → AUTHORIZED → CAPTURED → SETTLED
FAILED (from PROCESSING: declined / timeout) · VOIDED (from AUTHORIZED: released, never captured) · REFUNDED (from CAPTURED or SETTLED: via a new refund transaction — never deletion)

Must-haves

1. Treats idempotency as a first-class concern: client-supplied idempotency keys with 24h TTL, stored in Redis or DB, replay returns the original response.
2. Designs a double-entry ledger (every transaction = 2 entries: debit + credit) and explains why a single ‘balance’ table is wrong.
3. Names the payment state machine explicitly: CREATED → PROCESSING → AUTHORIZED → CAPTURED → SETTLED, and what triggers each transition.
4. Sizes throughput (~1,160 TPS avg, ~3,500 TPS peak), ledger growth (~200M rows/day), 7-year retention (~256 TB).
5. Addresses PCI DSS scope: tokenization at the ingress, raw card data never stored in our systems, all storage references tokens.

Red flags

• Updating a single ‘account_balance’ column instead of using a ledger — corrupts under any concurrent write or partial failure.
• No idempotency story — client retries result in duplicate charges, every time.
• Storing raw card numbers anywhere in the application — PCI DSS violation, $1M+/yr compliance cost increase.
• Treating the PSP (Stripe / Adyen) as ‘just call this API’ with no retry / state reconciliation — guarantees stuck transactions.

The ten trap claims — each one is wrong

1. “payment is a single synchronous step”
2. “just check if payment already exists”
3. “the PSP handles idempotency”
4. “eventual consistency is fine for payments”
5. “refund just deletes the payment record”
6. “encrypt the card numbers and store them”
7. “update the balance column directly”
8. “fire-and-forget webhooks”
9. “publish to Kafka then write to DB”
10. “Kafka guarantees global ordering”