Problem statement
Design the backend for a digital wallet where users hold a stored balance, top it up, spend it, and transfer it to one another (think the wallet inside a popular payments app). Money movement must be recorded on a double-entry ledger that is the single source of truth for every balance.
Operating context. Tens of millions of accounts, each with one or more balances (per currency). Peak load is roughly 20000 transfer requests/sec, read-heavy on balance/history lookups at about 200000 reads/sec. Money is denominated in integer minor units — never floats. A transfer debits one account and credits another atomically; the sum of all ledger entries for a currency must always net to zero. Clients retry aggressively, so the same logical transfer may arrive many times and must post exactly once. Regulators can demand a full, tamper-evident history of any account at any time.
Out of scope. Card-network / bank-rail integration, KYC and fraud scoring, foreign-exchange rate sourcing, the mobile UI, and tax reporting. Assume upstream services hand you validated, authenticated transfer intents.
What to produce. A high-level architecture covering: the request path for a transfer and for a balance read; the ledger data model (accounts, entries, transactions) and how you keep debits and credits balanced; how you enforce exactly-once posting under client retries; how you represent authorization holds that reserve funds before capture; how account and ledger data are sharded as volume grows; and how you make the history immutable and auditable. Sketch the components and the flow between them; we will probe consistency and failure handling during 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
- Data SQL
- Consistency Strong
- Reliability Idempotency
- Geo Sharding