Problem statement
Design the core double-entry ledger that sits behind a digital bank or wallet. Every movement of money is recorded as a balanced set of postings whose debits equal credits, and the ledger is the single source of truth for account balances. The overriding property is that money is never created or destroyed: the sum of all postings in a transaction is always zero.
Operating context. The ledger receives transactions from upstream services (payments, transfers, fee engines) and must record each one atomically. Balance reads dominate the workload — apps and dashboards poll them constantly — while writes are steady but spiky at settlement windows. Assume single-currency accounts, roughly 5000 postings/sec sustained, and a hard requirement that every posting is immutable and independently auditable for years.
Out of scope. KYC and onboarding, fraud and limit checks, currency conversion, the upstream payment rails themselves, and the reporting UI. Assume separate teams own each of those and hand you already-authorized transactions.
What to produce. A high-level architecture covering: the posting API and how a multi-leg transaction commits atomically or not at all, the data model (accounts, journal entries, postings), how you enforce the debits-equal-credits invariant, the partitioning scheme for accounts and the journal, idempotency for retried transactions, the balance read path, immutability and audit, and behavior under node failure or region failover. Sketch the components and the write/read flows; we will probe specifics in checkpoints.
Requirements
This assessment is a Premium feature.
The statement above is free to read. The functional and non-functional requirements, and the graded canvas that scores your design against them, come with Premium.
Topics
- System Design HLD
- Fintech Ledger
- Data Consistency
- Patterns Idempotency
- Data Partitioning