Design a Double-Entry Ledger
Our payments platform moves money for millions of businesses: charges, refunds, fees, payouts and currency conversions. Today every product team keeps its own balance tables, and each month finance spends a week explaining why the numbers disagree. We want a single system of record for money.
This brief is incomplete on purpose, as it would be in a real interview. Ask the interviewer about the users, the features, the targets and the traffic. Whatever you uncover is added below.
Nothing uncovered yet.
Nothing uncovered yet.
Nothing uncovered yet.
- The data model for accounts, transactions and entries
- How a transaction is posted, including the checks that run
- How balances are read, now and in the past
- The capacity estimate behind your choices
Accounts, transactions and immutable entries (account, signed amount, currency, transaction id); every transaction's entries sum to zero per currency, enforced at posting; corrections are reversing transactions; balances are derived from entries.
All entries of a transaction and the affected balances are committed atomically, an idempotency key is stored under a unique constraint, overdraft rules are checked against the balance inside the same transaction (row locks or conditional updates), and reads after a post see it.
Accounts on most transactions (fees, FX) are split into many sub-accounts or receive their entries through an aggregated, asynchronous path whose pending total is still accounted for, so they are not a single lock every posting waits on.
Accounts are partitioned (for example by business) so most transactions stay within one partition, cross-partition transactions are handled explicitly, and append-only entries move to cheaper storage over seven years.
Point-in-time balances come from periodic balance snapshots plus the entries after them; a daily trial balance checks that all accounts sum to zero per currency, and every balance can be recomputed from entries.
Every functional requirement in the brief is visibly served by something on the board, and the non-functional targets are addressed rather than ignored.
Components are labelled, data flows are drawn as connections between them, and the direction of each flow is unambiguous.
Concentrate on recording money movements and serving balances. Card networks, bank integrations, pricing and the finance team's reports are out of scope: product teams will call your ledger with the movements they need recorded.
- Views
- 3