Design a Payment Ledger

Design a Payment Ledger

Step 1 of 12

throughput2 000 /s

Move 40.00 from A to B. One rule shapes the rest: no row is ever updated.

The Idea

Record money moving so any balance can be explained line by line. Assume 2 000 transfers a second and one rule that shapes everything else: no row is ever updated in place — every change is a new entry.

Real-World Example

A shop's till roll. You do not rub out a sale that went wrong; you ring a refund through and both lines stay on the roll, so the drawer and the paper still agree at closing time.

The Tradeoff

Double entry writes two rows that must commit together, which is where you accept a transaction and give up easy sharding. Balances are then derived by summing entries — correct, and slower every year — so a periodic snapshot is what keeps today's balance a short sum.

Your turn

Put the steps in the right order.

1. 1Read a balance as the snapshot plus the entries after it↑↓
2. 2Accept the transfer under an idempotency key so a retry is not a second payment↑↓
3. 3Commit the debit row and the credit row in one transaction↑↓
4. 4Refuse the write if the two sides do not sum to zero↑↓

Check order

Mini quiz

1 / 3

Entries are append-only because:

• AAppending is faster than updating
• BAn edited row destroys the history that explains the balance
• CDatabases cannot update rows safely
• DIt removes the need for indexes