Hard · Finance and payments
Bank ledger
You run the system of record for a regional bank: every deposit, withdrawal and card settlement is a posting that must be exact and permanent. Customers in two continents read balances all day, and regulators can ask for proof at any time. A bad day for you is a loss of even one posting. Practise this hard system design problem for free with a Google or GitHub account.
The brief
You run the system of record for a regional bank: every deposit, withdrawal and card settlement is a posting that must be exact and permanent. Customers in two continents read balances all day, and regulators can ask for proof at any time. A bad day for you is a loss of even one posting.
Think of the core ledger of a bank.
Users, scale and requirements
- Who uses it
- 400,000 customers
- Audience in plain numbers
- 400,000 users or devices
- Normal peak
- ≈ 6,000 requests per second
- Request mix
- Read: 50%; Payment: 30%; Sign-in: 10%; Write: 5%; Report: 5%
- Speed for 99 of 100 requests
- Read: ≈ 700 ms; Payment: ≈ 500 ms; Sign-in: ≈ 1,000 ms; Write: ≈ 700 ms; Report: ≈ 6,000 ms
- Successful requests
- 99.9%
- Data safety
- No acknowledged write may be lost.
- Monthly budget
- ≈ $33,000
- Data at rest
- ≈ 8 TB
- Where users are
- North America: 60%; Europe: 40%
- Home region
- North America
- Waiting deadlines
- Read: 900 seconds; Payment: 3,600 seconds; Sign-in: 900 seconds; Write: 3,600 seconds; Report: 3,600 seconds
- Minimum retained history
- 2,555 days on authoritative stores
- Fresh reads
- People must see their own changes. At most 0.1% of reads may be stale in the model.
- Personal reads
- 90% of reads are private; a shared public copy cannot answer them.
- Required proofs
- Audit trail; Managed encryption keys; Tested backups; Signed-in access; Retention rules
≈ marks an approximation, just as in the game. Waiting deadlines measure the age of queued work and are separate from interactive response time.
- A posting is one double-entry record: a debit and a credit.
- Recovery time target: 15 minutes. Recovery point target: zero.
- Scored data retention: at least 2555 days on active authoritative stores. Copies used only for search or reports can be rebuilt. Local device history and rollup policies still require the separate protocol check.
Questions that shape the design
Can a posting ever be edited or deleted?
Never. Corrections are new postings. The ledger is append-only.
How much data can we lose in a disaster?
None for acknowledged postings. If a region is lost we may be down for minutes, but not wrong.
Where are customers?
About 60 percent in North America and 40 percent in Europe.
What must we prove to the regulator?
An audit trail, encryption with managed keys, tested backups, signed-in access and long retention.
The traffic day
Traffic concentrated in working hours. The clock covers 00:00 to 24:00 in the home region. Events add pressure on top of that normal traffic.
10:15 · Database failover
The primary database dies. Recovery depends on the standby and failover settings.
Duration: ≈ 60 seconds.
13:00 · Bad migration
A buggy data change damages rows, and replicas copy the damage.
Affected share: 5%.
15:30 · Region outage
A whole cloud region goes down.
Duration: ≈ 3,600 seconds.
18:00 · Compliance audit
An auditor checks your design: who did what, encryption keys, personal data, backups and consent.
What a strong design has to handle
- Which copy of the data is the truth during a failover? A write that only reached one copy can disappear.
- Commit balanced postings exactly once and prevent concurrent overspending.
- Sync replication across zones adds about 2 to 5 ms to every posting and is the price of never losing an acknowledged one.
- Active-active costs about 100 percent of the primary region again and recovers in about 30 seconds with nothing lost. A warm standby costs about 40 percent and takes about 15 minutes; pilot light costs about 10 percent and takes about an hour. A zero recovery-point target leaves only active-active (approx.).
Make a prediction, run a full traffic day, then compare the result. The in-game editorial opens after a finished day and includes measured reference designs.
Concepts to practise
Related problems
- Medium
Peer-to-peer wallet
People split dinner by sending each other money from their phones. A transfer takes money from one balance and adds it to another, and the sender must see the new balance right away. A flaky mobile connection often makes the app send the same transfer twice.
- Hard
Crypto exchange
People trade coins, check prices and withdraw funds around the clock from every continent. A sudden price crash makes everyone log in and trade at once, attackers flood you hoping to knock the site over, and a leaked key could empty a wallet. Balances must never be wrong.
- Hard
Object storage service
Customers store billions of files, from tiny pictures to huge videos, and fetch them by name. The service must never lose a file, scale without a limit and stay cheap. Most files are written once and rarely read again.
- Medium
Patient health records
A hospital network keeps patient charts, orders, notes and scanned documents for 40 hospitals. Doctors need a chart in under a second, no saved note may be lost when a server or a building fails (in a whole-region disaster, at most the last minute of edits may need re-entering from the ward), and an auditor can walk in any day and ask you to prove who looked at what.