Art of Codeartofcode
Lesson 11 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.10 How do you keep it consistent?

3 min read+10 XP

Where strong consistency is required, and where it isn't:

  • Strong: the intent's state change and its ledger transaction are written in one database transaction (Chapter 17). Either both happen or neither.
  • Exactly once in effect: the outbox row for the merchant webhook is written in that same transaction, then published at least once (Chapter 23); merchants de-duplicate by event ID.
  • Eventual, and that's fine: dashboards, analytics, search over payments and merchant reports can lag by seconds or minutes.
  • Sharding: shard by merchant (or account) so a payment's intent and ledger lines live on one shard; cross-shard movements (rare: platform-wide accounts) use a saga with compensating ledger transactions, never a silent partial write.
  • Clocks: use database time or an ordered ID for ledger ordering, not server clocks.

Memory code: "State and money change together, in one transaction; everything else can catch up."