LeetDesign
← All problems
Medium

Design a Payment Ledger

Move money under the strictest contract in the catalog — zero staleness, zero loss, quorum everything — at a load that barely fills one database. The grade here is discipline, not scale.

Design the ledger at the heart of a payments product. Clients post transactions — debits and credits that must never be lost, never double-applied, never reordered into an overdraft — and read account balances before authorizing the next payment.

Money flips every dial to its maximum. A balance read must reflect every committed transaction — authorizing against a stale balance is spending money that may not exist — so nothing that ages, expires, or lags may sit between a read and the truth. An acked write may never vanish: zero RPO, three copies, a quorum before you say "done". And the ledger must hold all of that through a node failure and through the loss of an entire availability zone, at four nines.

Then look at the load: a couple of thousand transactions a second at the payday peak, a few thousand balance checks alongside. Nothing about this traffic is big, and half a billion ledger rows is smaller than it sounds. Every requirement is absolute — and none of them are expensive unless you make them so.