Layer 3 · Go deeper · 12 min
Go deeper
Size it, build it, then make the calls an interviewer will push you on.
Back of the envelope
Size it up
Tap through each step of the arithmetic.
What does a festive-sale opening throw at the ledger?
How many shards absorb that peak?
Can one balance row keep up with commission revenue?
How much does ten years of history weigh?
Build-up · 6 steps
Build the high-level design
One requirement at a time on a single PostgreSQL primary with a synchronous replica, ending with a ledger that works at moderate load.
Step 1 of 6
Post a balanced entry
Payments arrive through an outbox, Kafka and ingest workers; the wallet calls synchronously because it needs a yes or no. Product teams say what happened; the ledger’s templates decide which accounts move.
6 interview moments
You’re the candidate
The interviewer pushes on the hard parts. Pick an approach and see how it holds up.
Deep dive 1 of 6
Interviewer
“Template bugs, crashes between legs and redelivered events all threaten the books. How does every entry balance and post exactly once?”
Your move. Pick an approach:
Deep dive 2 of 6
Interviewer
“Payouts need the balance now, support needs a statement, finance needs 31 March at 23:59. How do you serve all three fast?”
Your move. Pick an approach:
Deep dive 3 of 6
Interviewer
“Commission revenue takes 5,200 postings a second at the festive peak. One locked balance row takes 400. What do you do?”
Your move. Pick an approach:
Deep dive 4 of 6
Interviewer
“Eight shards by account owner. A capture touches system accounts and a seller; a wallet transfer, two customers. How do entries stay atomic?”
Your move. Pick an approach:
Deep dive 5 of 6
Interviewer
“A ride reserves ₹2,000 from a wallet; the fare comes to ₹1,640. How does the ledger hold money before moving it?”
Your move. Pick an approach:
Deep dive 6 of 6
Interviewer
“An auditor asks: does it balance, does it match the outside world, has anyone changed history? How do you answer?”
Your move. Pick an approach:
Build-up · 8 steps
Follow one payment through the ledger
Writes reach the shards through one API; everything that summarises, archives or checks the ledger reads its change stream.
Step 1 of 8
Record
The payment service commits each money event with an outbox row. Ingest workers map it through a versioned template and post in small batches, keyed by the event ID, so a redelivery can’t double-post.