Round one: “design a wallet”

Two sentences. Notice what is absent: no currency, no scale, no latency target, no mention of where money enters the system from, no definition of what "hold" means legally or technically. That absence is the first exercise.

The temptation is to fill the gaps with assumptions and start drawing. The correct move is to fill them with questions, pick the three or four whose answers would change your architecture, and ask those.

What we are building toward

For the rest of this module the system has a name and a shape: a core banking platform at 20 million customers and 10 million transactions a day, with wallets, loans, cards, six payment rails and four jurisdictions. But the interviewer has not said any of that yet. They will reveal it one round at a time, which is exactly how product requirements actually arrive.

Here are the questions that earn their forty seconds, with what each answer actually decides. Ask four; hold the rest in reserve.

The answers for this module

The interviewer, being reasonable, answers the first four and defers the rest:

Note the two "for now"s and the "later". The interviewer is telling you the roadmap. A design that makes currency hard to add is already wrong, even though currency is out of scope today. This is the difference between scoping and ignoring.

Written as verbs, with an actor. The discipline of the verb form is what surfaces the missing pieces.

Requirement 6 is the one candidates omit, and it is the most important sentence in the round. It is not a feature a user asked for; it is the property that makes the system a ledger rather than a spreadsheet. Everything structural in this part exists to satisfy it.

The interviewer said "a few thousand users". Take them at their word for the design, but state the numbers so that later rounds have something to break.

The tradeoff to name now, out loud

Durability and latency are in direct tension, and the resolution should be stated as a choice rather than discovered later:

Before any schema, one rule that is not negotiable and is worth the thirty seconds it takes to justify.

IEEE 754 binary floating point cannot represent most decimal fractions exactly, because it stores a binary fraction. One tenth is 0.0001100110011… repeating in binary, so 0.1 is stored as the nearest representable value, which is slightly off. Arithmetic then compounds that error:

0.1 + 0.2 === 0.30000000000000004

0.1 * 3 === 0.30000000000000004


          after 10,000 additions of 0.01 the drift is visible in the 7th decimal

          across 10M transactions a day, that drift becomes real money
          you cannot account for

The rule

Store money as an integer count of the currency's smallest unit, its minor unit. ₦1,250.75 is stored as 125075 kobo. $10.00 is 1000 cents. All arithmetic is integer arithmetic, which is exact.

In the language we will use for examples, that means bigint throughout, never number:

// exact, integer kobo
const balance: bigint = 125075n;      // ₦1,250.75
const debit:   bigint = 50000n;       // ₦500.00
const after         = balance - debit;  // 75075n, exact always

// and formatting reads the exponent, never assumes 2
function format(minor: bigint, exponent: number) { ... }

Start where most people start, because understanding precisely why it fails is what makes the alternative feel inevitable rather than arbitrary.

CREATE TABLE wallets (
  id          UUID PRIMARY KEY,
  customer_id UUID NOT NULL,
  balance     BIGINT NOT NULL DEFAULT 0,   -- kobo
  currency    CHAR(3) NOT NULL
);

CREATE TABLE transfers (
  id       UUID PRIMARY KEY,
  from_id  UUID NOT NULL REFERENCES wallets(id),
  to_id    UUID NOT NULL REFERENCES wallets(id),
  amount   BIGINT NOT NULL CHECK (amount > 0),
  created_at TIMESTAMPTZ NOT NULL DEFAULT now()
);

And the transfer:

BEGIN;
  UPDATE wallets SET balance = balance - 50000 WHERE id = 'A';
  UPDATE wallets SET balance = balance + 50000 WHERE id = 'B';
  INSERT INTO transfers (...) VALUES (...);
COMMIT;

This is not stupid. Inside one transaction it is atomic, the two updates are applied together, and the balance read is a single indexed lookup, the fastest possible. For a few thousand users it would run for years.

Three defects, in increasing order of seriousness

One: it does not check the balance. Easily fixed, and the fix is instructive:

UPDATE wallets SET balance = balance - 50000
 WHERE id = 'A' AND balance >= 50000;
-- then: if rows affected = 0, the balance was insufficient. Roll back.

Putting the check in the WHERE clause rather than in a prior SELECT is the difference between a correct program and a race condition. We will formalise why in the next chapter.

Two: the history is not the truth. The transfers table is a log that happens to sit beside the balance, but nothing structurally forces them to agree. A bug that updates balance without inserting a transfer leaves no trace. There is no way to answer "why is this balance what it is?" except to trust it.

Three: there is no way to prove conservation. Requirement 6 said the system must be able to demonstrate that money was neither created nor destroyed. With balances as independent columns, the only check available is "does the sum of all balances equal what we think it should?", and "what we think it should" has no independent source. The invariant is unverifiable, which means in practice it is violated silently.

Before we fix the model, see the failure that makes read-then-write unsafe. This is the single most common money bug in the world, and it is worth being able to draw it from memory.

What just happened, in words

Two withdrawals of ₦600 arrive at the same moment against a wallet holding ₦1,000. Both transactions read 1000. Both compute 1000 - 600 = 400. Both write 400. The second write overwrites the first. It is not lost in the sense of vanishing, it is lost in the sense of being forgotten. The account has paid out ₦1,200 and shows a balance of ₦400. ₦600 has been created from nothing.

          start: 1000

          T1 reads 1000, T2 reads 1000   ← both see the same
          value

          T1 writes 400, T2 writes 400

          end: 400, but 1200 was paid out


600 kobo created from nothing. the ledger no longer sums to zero

Why SELECT then UPDATE cannot fix it

The instinct is to check first. It does not help, because the check and the write are two separate points in time:

-- UNSAFE. The gap between these two statements is the bug.
SELECT balance FROM wallets WHERE id = 'A';   -- 1000. Fine, proceed.
                                                 -- ← T2 commits here
UPDATE wallets SET balance = 400 WHERE id = 'A';   -- overwrites

Under the default isolation level of most databases, READ COMMITTED, nothing prevents this. Both transactions are individually valid. Neither observes anything inconsistent. The database is behaving exactly as documented.

The three fixes, in order of preference

All three are covered properly in Part 2, including what the lock manager is actually doing. For now the point is narrower: the balance must never be computed in application memory and then written back.

Double-entry bookkeeping is roughly eight hundred years old, invented by Italian merchants and formalised by Luca Pacioli in 1494. It survived because it has a property no other model has: it makes errors visible arithmetically.

The rule

Money is never created or destroyed; it only moves between accounts. Therefore every movement is recorded twice, once as a debit and once as a credit, and for any transaction, the entries must sum to zero.

Debit and credit, without the accounting confusion

The words are counter-intuitive because they are stated from the bank's perspective, not the customer's. Skip the vocabulary argument entirely by treating them as signs:

          debit  = −  (value leaves this account)

          credit = +  (value arrives at this account)


          invariant:  Σ signed amounts, per transaction, per currency = 0

The schema

-- an account is anything money can sit in: a customer wallet,
-- a company account, a fee revenue account, a suspense account.
CREATE TABLE accounts (
  id        UUID PRIMARY KEY,
  kind      TEXT NOT NULL,      -- customer_wallet | company | fee_revenue | suspense
  owner_id  UUID,                -- null for internal accounts
  currency  CHAR(3) NOT NULL,
  CHECK (kind <> 'customer_wallet' OR owner_id IS NOT NULL)
);

-- the journal: one row per business event. The narrative.
CREATE TABLE journal (
  id              UUID PRIMARY KEY,
  kind            TEXT NOT NULL,   -- transfer | fee | reversal | disbursement
  idempotency_key TEXT UNIQUE,      -- the duplicate-proof, see ch 28
  created_at      TIMESTAMPTZ NOT NULL DEFAULT now()
);

-- the entries: the money itself. Append-only. Never updated, never deleted.
CREATE TABLE entries (
  id          BIGSERIAL PRIMARY KEY,
  journal_id  UUID NOT NULL REFERENCES journal(id),
  account_id  UUID NOT NULL REFERENCES accounts(id),
  amount      BIGINT NOT NULL,      -- signed minor units. negative = debit.
  currency    CHAR(3) NOT NULL,
  created_at  TIMESTAMPTZ NOT NULL DEFAULT now()
);

CREATE INDEX ON entries (account_id, id DESC);  -- history, newest first
CREATE INDEX ON entries (journal_id);            -- all legs of one event

A transfer of ₦500 from A to B becomes one journal row and two entries:

Why this makes errors visible

Because the invariant is now a query anyone can run:

-- must return zero rows. If it ever returns one, money was created.
SELECT journal_id, currency, SUM(amount) AS drift
  FROM entries
 GROUP BY journal_id, currency
HAVING SUM(amount) <> 0;

That is requirement 6, satisfied. Not by trust, by arithmetic. Part 10 turns this query into a continuously-running alarm.

With entries as the source of truth, a balance is no longer stored. It is computed:

SELECT COALESCE(SUM(amount), 0) AS balance
  FROM entries
 WHERE account_id = $1 AND currency = $2;

This is strictly better in three ways, and strictly worse in one. Both halves matter.

The one defect, and why we accept it for now

An account with 400,000 entries requires summing 400,000 rows to answer "what is my balance". At round-one scale (thousands of users, thousands of entries) this is a few milliseconds and entirely fine. At 10 million transactions a day it is catastrophic, and the fix is snapshots plus a cache, which is chapter 38 in Part 3.

Time-travel, for free

The property that repays the cost more than any other. Because entries are append-only and monotonically ordered, any historical balance is one clause away:

-- balance as it stood at any past instant
SELECT SUM(amount) FROM entries
 WHERE account_id = $1 AND created_at <= '2026-03-14 09:00:00+01';

When a customer disputes a balance from three months ago, or a regulator asks for a position at year-end, or an incident requires knowing what the system believed at 03:47: this is the difference between an afternoon's work and an impossible question.

The whole round-one design. Deliberately, almost aggressively simple.

The posting transaction in full

BEGIN;

  -- 1. duplicate-proof. UNIQUE violation here means we have seen this before.
  INSERT INTO journal (id, kind, idempotency_key)
  VALUES ($jid, 'transfer', $key);

  -- 2. the debit, with the balance check fused into the write.
  --    the sub-select is evaluated under the row locks this statement takes.
  INSERT INTO entries (journal_id, account_id, amount, currency)
  SELECT $jid, $from, -$amt, $ccy
   WHERE (SELECT COALESCE(SUM(amount),0) FROM entries
            WHERE account_id = $from AND currency = $ccy) >= $amt;
  -- 0 rows inserted ⇒ insufficient funds ⇒ raise and roll back.

  -- 3. the credit.
  INSERT INTO entries (journal_id, account_id, amount, currency)
  VALUES ($jid, $to, +$amt, $ccy);

  -- 4. belt and braces: assert the invariant before we allow the commit.
  --    cheap (two rows), and it converts a silent corruption into a loud failure.
  DO $$ BEGIN
    IF (SELECT SUM(amount) FROM entries WHERE journal_id = $jid) <> 0
    THEN RAISE EXCEPTION 'ledger imbalance on %', $jid;
    END IF;
  END $$;

COMMIT;

What each piece buys

"I'd use Postgres" is an assertion. What follows is the justification, and it is the kind of depth that distinguishes a senior answer: not just which guarantee, but what the database is physically doing to provide it.

The guarantee we need, precisely stated

Two INSERTs into entries and one into journal must become visible to every reader at the same instant, and must survive a power failure occurring one microsecond after acknowledgement. That is atomicity plus durability across multiple rows in multiple tables.

How atomicity is actually achieved

Not by holding the writes in memory until commit. Postgres writes tuples into shared buffers as it goes, and each tuple carries the transaction id (xmin) that created it. Visibility is then a function of that id:

          every row carries xmin (creating txid) and xmax (deleting txid)


          a row is visible to a reader if:

            xmin is committed  and  xmin < my snapshot

            and  xmax is unset, aborted, or > my snapshot


so "atomic" = flipping ONE bit in the commit log

The commit status of a transaction lives in the commit log (pg_xact), at two bits per transaction. Before commit, those bits say in progress and every one of our three rows is invisible to everyone else. At commit, the bits flip to committed, and all three rows become visible simultaneously, because visibility was always derived from that single location. Atomicity across rows is achieved by making multi-row visibility depend on a single-bit write. That is the trick, and it is elegant.

How durability is actually achieved

Write-ahead logging. Before any data page is modified on disk, the intention is written to a sequential log and flushed:

          1. modify pages in shared buffers  (memory, fast but not durable)

          2. append WAL records describing the change  (sequential)

          3. fsync the WAL  ← the durability point. ~1–10 ms on NVMe

          4. acknowledge the commit to the client

          5. flush dirty data pages later, lazily, at a checkpoint


          crash between 4 and 5 → replay the WAL on startup, no loss

Two properties make this fast enough to be acceptable. The WAL is sequential, and sequential writes are roughly an order of magnitude cheaper than random ones. And commits from concurrent sessions are group-committed, so one fsync can durably commit dozens of transactions, so throughput does not fall linearly with the flush cost.

Why not the alternatives, for this table, at this scale

The honest summary to give in the room:

Close the round by listing your own design's failure modes before the interviewer does. Each line here becomes a later part. This list is the rest of the module.

The closing line for round one

You have now named the next round yourself. The interviewer's follow-up is almost always one of the two you flagged, and Part 2 takes the second.