Loading…

Design a Payments Ledger (double-entry)

hardSystem design40 min5 stagesPro

Asked atStripePayPalSquareWiseCoinbaseAdyenBlockUber

Design the core money ledger behind a payments platform. Every customer, merchant, fee pool, and FX reserve is an account; money moves between them as transfers. The catch is that this is money — you can never lose a cent, never create one, never double-post a retried request, and you must be able to prove years later exactly how any balance came to be. The naive "UPDATE accounts SET balance = balance - amount" is the trap; the real design is an immutable double-entry journal where balances are derived, postings are atomic and idempotent, and the books always reconcile to zero.

Best after a few full reps. Expect follow-up questions, edge cases, and deeper trade-off discussion.

What this problem tests

Core APIsIdempotency / Exactly-OnceMoney RepresentationCore ComponentsSource of Truth & AtomicityBalance Topology

Round shape

5 stages

Time budget

40 min

Feedback loop

Grade anytime

Guided practice·Primary loop

Guided practice

Workspace-first, hints visible, stage retry available. The cheap, repeatable loop — build the answer shape before you take it under pressure.

Stage-by-stage workspace instead of a blank page.
Grade one stage or the whole answer whenever you want.
Compare your reasoning against reference criteria and model answers.

Solve once, compare against the checklist, then come back to the weak stage instead of starting over.

Mock interview·Pressure test

Mock interview

Strict timer, hints hidden, debrief deferred to the end. Use this once you can already structure a clean answer and want to pressure-test pacing and pushback.

Best once the answer shape is already in your head.
Pressure-test pacing, pushback handling, and communication.
Use diagnosis after the interview for exact misses and next study steps.

Best after one structured rep · timed · focused on pacing and communication.

Requirements

This is the framing pass. A strong answer quickly defines what the system must do, what quality bar it has to hit, and the numbers that will justify the rest of the design.

First 5 min of the round

What must exist

Functional Requirements

5 items

1Record a money movement — post a transfer that moves money between accounts as balanced postings.

2Read the current balance of an account.

3Produce an account statement (transaction history) over a time range.

4Exactly-once posting: a retried transfer with the same idempotency key never double-posts.

5Corrections are compensating reversals — entries are never edited or deleted.

What good looks like

Non-Functional Requirements

4 items

1Strong consistency on the write path — correctness over availability. Never lose or create money.

2The whole ledger reconciles to zero; every transaction is balanced.

3p99 < 100ms to post, p99 < 50ms to read a balance.

4Durability: a committed posting is never lost; journal retained 7+ years.

Numbers to anchor the design

Scale Estimation

4 items

1~10,000 transfers/sec at peak. Each transfer writes ≥2 entries → ~20,000+ postings/sec.

2~250M transfers/day → 500M+ journal entries/day, and the journal is append-only so it grows forever — at a few hundred bytes/entry that is hundreds of GB/day, many TB/year, retained for years.

3~50K balance reads/sec — read-heavy, but each read can gate a write so it must be accurate.

4Load is skewed: a few hot accounts (the platform fee pool, an FX reserve) take a leg of a large fraction of transfers.

How the round unfolds

Each stage has a distinct job. Treat them like separate deliverables instead of one giant answer, and the round becomes much easier to navigate.

4 design stages · 40 pts after framing

🔌

Stage 2~5 min10 pts

API Design

Define the contract clearly: the endpoints, auth boundary, error semantics, and the one or two decisions that matter most.

What you should produce

Now define the API. What endpoints does the ledger expose? Think about the post-transfer contract, how a retry is made safe, how a balance is read,...

Strong answers cover

Core APIsIdempotency / Exactly-OnceMoney Representation

🏗️

Stage 3~10 min10 pts

High-Level Architecture

Lay out the main components and trace the write path, read path, and any async path cleanly.

What you should walk through

Walk me through the architecture.

Strong answers cover

Core ComponentsSource of Truth & AtomicityBalance Topology

📝

Stage 4~10 min10 pts

Data Model

Let's get concrete about the schema. What does a journal entry look like, how do you guarantee a transaction is balanced, how is a balance derived, and how is money stored?

Prompt you should be ready for

Let's get concrete about the schema.

Strong answers cover

Journal & Double-EntryImmutability & Derived BalanceMoney & Idempotency Storage

📈

Stage 5~10 min10 pts

Scaling & Deep Dive

Name the first bottleneck, failure modes, and the trade-offs that keep the system fast and reliable under pressure.

What you should pressure-test

Let's stress the design. Where does it bottleneck at peak, how do you keep balance reads fast, how do you prove the books are correct, and how do y...

Strong answers cover

Bottlenecks & Hot AccountsSnapshots & ReconciliationConsistency & Durability

What a strong first rep looks like

Scope clearly

Translate the prompt into concrete requirements, scale, and trade-offs before drawing architecture.

Stay stage-specific

Give APIs in the API stage, data models in the storage stage, and failure modes in scaling. Don't blur them together.

Iterate fast

Grade early, compare to the reference reasoning criteria, fix the biggest misses, and re-submit the weak stage instead of starting over.