Functional Requirements

1. Players should be able to transfer currency to each other: exactly once, never overdrawing, and safely retryable.
2. The economy should mint and destroy currency through quests and shops, inside budgets that someone owns.
3. Players should be able to read balances and analytics: 24-hour flows and a 30-day balance series, with stated freshness.
4. Corruption and exploits should be detected in seconds, and the economy can be frozen while money is put back.

Below the line (out of scope):

• Real-money payments and payment processors. This ledger moves one in-game currency.
• Item and inventory trading. Worth one sentence if asked: items would be another ledger, not rows in this one.
• Fraud ML beyond velocity caps. The caps are the in-scope hook a fraud team would later feed.
• Multi-region active-active. Explicit cut, defended in deep dive 6: one region of record plus a DR replica, nothing merged.

Non-Functional Requirements

1. No double-spend and no negative player balance, enforced inside the database, never by app-side check-then-act. Transfers are never approximate, and amounts are integers only.
2. The slowest 1% of transfers still complete in under 150ms (p99) at peak.
3. Analytics may lag by seconds and must say so: every derived read carries an asOf timestamp. The truth path and the read models share no fate.
4. Corruption is detected in seconds and a freeze lever exists. The nightly full recompute is the backstop, not the front line.

Defining the Core Entities

• Account holds a balance and a floor. Player accounts floor at 0, so overdraft is impossible. System accounts (quest faucets, shop sinks) floor at -budget, with a named owner. One column, one guard, two jobs.
• Transfer is one requested movement, with a lifecycle (PENDING → COMPLETED or REJECTED) and a reversal_of field, so a refund is a new opposite transfer pointing at the original, never an edit.
• Ledger entry (leg): every transfer writes two, minus on the sender and plus on the receiver, always summing to zero. Each leg records balance_after and a per-account sequence number, allocated inside the balance-moving transaction, so there are no mixed clocks.
• Rollups are per-account, per-hour summaries computed FROM the ledger. Derived, rebuildable, never the truth.

API or System Interface

POST /v1/transfers        Idempotency-Key: key   // scoped (actor, key)
  { to, amount }          // sender = auth session, never the body
  → 201 COMPLETED | 202 PENDING   // 202 = cross-shard or queued; poll the GET
  → 422, body: { error: INSUFFICIENT_FUNDS | ACCOUNT_CLOSED | ACCOUNT_FROZEN | FAUCET_BUDGET }
  → 409, body: { error: KEY_REUSED }   // same key, different body
GET  /v1/transfers/{id}                         // got a 202? ask here until COMPLETED or REJECTED
GET  /v1/accounts/{id}/balance                  → { balance, asOf }
GET  /v1/accounts/{id}/flows?window=24h         → { inflow, outflow, windowStart, windowEnd, asOf }
GET  /v1/accounts/{id}/balance-series?days=30   → { points: [{hourUtc, closingBalance}], asOf }

• Same key with the same body replays the stored outcome, so retries are exact, not accidental. The same key with a different body is a 409, because silently picking one body would hide a client bug that involves money.
• 202 PENDING is a first-class state shared by exactly two paths: the cross-shard saga (deep dive 2) and the hot-sender queue (deep dive 5). Both resolve through the same GET.
• Validation before any money moves: amount > 0, to ≠ actor, amount ≤ cap. The gateway rate-limits mutations; analytics reads are authorized to the account owner or a service principal.
• Every derived read carries asOf. Freshness is part of the contract, not a footnote.

1) Players can transfer currency to each other

• The sender is the authenticated session, never the request body, so no client can debit an account it does not own by construction.
• The whole movement is one ACID transaction in a sharded SQL ledger: idempotency anchor insert, two single-row locks in explicit sorted order, one fused guard, two legs, status, one commit. Deep dive 1 opens it statement by statement.
• Rejection also commits. A failed guard marks the transfer row REJECTED and commits, because nothing changed and the anchor row must survive for retries to find.
• Reads split by purpose: spending reads hit the primary, display reads hit replicas and are marked stale.

2) The economy mints and destroys currency, inside budgets

• A quest reward is an ordinary transfer from a faucet account to the player. A shop fee is a transfer into a sink. There is no special mint path to secure separately.
• The faucet's floor is its negative budget, so the same fused guard that stops player overdrafts caps minting. A compromised payout service hits the budget wall (422 FAUCET_BUDGET) instead of printing forever.
• Budgets deplete monotonically, so replenishment is on the board, not implied: the named owner tops the faucet up on a stated cadence with an approved transfer from a treasury account, which is itself budgeted.
• circulation = -SUM(faucet balances) - SUM(sink balances). Faucet balances are negative, so the number comes out positive. The ledger is the inflation dashboard; no separate metrics system exists to drift from it.
• "A quest pays every player 100 gold" is N ordinary transfers sent in batches against faucet sub-accounts that were split ahead of time, so the burst never hammers one row. Afterward SUM(delta) across all legs still reads exactly zero.

3) Players can read balances and analytics, with honest freshness

• CDC copies committed ledger rows into Kafka, keyed by account, so one account's history stays in order. It tails the commit log, never a dual write: if it did not commit, it does not stream.
• The rollup keeps a running total per (account, hour) in its own crash-safe state and flushes the bucket's current TOTAL. Never an increment. On a crash, state and read position rewind together, the same events replay, and identical totals overwrite themselves.
• An hour's closing balance is the balance_after of the last entry at or before hour end, where the entry's hour comes from a timestamp written in the same statement as the leg, and "last" means the per-account sequence number, one timeline, no mixed clocks. Idle hours carry the previous value forward, and late data corrects only the hours it touches. Nothing compounds.
• The 24h answer is 23 finished hours, plus the current partial hour, plus the slice of the oldest hour still inside the window. The partial hour is served from processor state; during a restart it falls back to the last flushed hour, and asOf admits it.

4) Exploits are detected in seconds, and the economy can freeze

• The integrity checker reads the same stream analytics reads, which is the whole trick: detection inherits analytics' seconds-level freshness for free.
• The stream is grouped by account, so a transfer's two legs land in two different groups. The checker regroups legs by transfer id and alarms if a leg stays unmatched past a few seconds.
• Three invariants: all legs sum to zero; each leg's balance_after equals the previous balance plus its own delta; MIN(player balance) ≥ 0. The third is not redundant: a bug that consistently double-spends the same coins passes the first two, and only the third catches it.
• Velocity caps (how fast and how much one account may send) catch abuse the balance guard cannot see: stolen accounts draining slowly, bots.
• Escalation ladder: freeze the account, then freeze the economy at the gateway (transfers 503, reads fine), then page a human. Cleanup is bulk reversals, compensating entries, never edits.
• The nightly full recompute over the hot database plus the cold tier is the backstop, not the front line.

• If they just nod and wait: "the riskiest box is the transfer transaction, shall I open it?"
• Running behind: protect dives 1 and 3.

1) How is a transfer exactly-once, with no double-spend?

• The enemy is the check-then-act window: read a balance, decide in the app, write a new balance. Two concurrent spends of the same coins both pass the read. The second enemy is the retry: a timeout plus a re-send must not move money twice.

BEGIN
  INSERT transfers(actor, key, A, B, amt, PENDING)   -- dup (actor,key): replay stored outcome / 409
  SELECT status FROM accounts WHERE id = min(A,B) FOR UPDATE   -- two single-row locks,
  SELECT status FROM accounts WHERE id = max(A,B) FOR UPDATE   -- explicit sorted order
      -- missing | CLOSED | FROZEN -> SET status = REJECTED; COMMIT; 422
  UPDATE accounts SET balance = balance - amt
    WHERE id = A AND status = ACTIVE AND balance - amt ≥ floor
      -- players: floor 0. faucets: floor -budget. One guard stops
      -- overdraft AND runaway minting. 0 rows -> REJECTED; COMMIT; 422
  UPDATE accounts SET balance = balance + amt WHERE id = B AND status = ACTIVE
      -- rows-affected checked here too: no crediting a closed account
  INSERT 2 ledger legs (each with balance_after, per-account seq)
  SET status = COMPLETED
COMMIT

accounts  (id PK, status, balance, floor)
transfers (id, actor, idem_key, from, to, amount, status, reversal_of,
           UNIQUE(actor, idem_key))              -- the anchor
legs      (transfer_id, account_id, delta, balance_after, seq,
           UNIQUE(account_id, seq))              -- chain-check; seq allocated in the balance-moving txn

2) What if the two accounts live on different shards?

• At 10-15K/s peak with TB-scale retention, the ledger shards by account id, and a transfer between two shards can no longer be one local transaction.
• Say the restraint first: do not build this until cross-shard pairs are measured as common. Same-shard placement of trading partners may defer it forever.

3) A dupe exploit starts at 2am. When do you find out?

• The domain sets the clock: a duplication exploit spreads on Discord in hours, so the market is dead before a nightly job wakes up. Detection latency is a product requirement, not an ops nicety.

4) The rollup crashes 3 seconds after a checkpoint. What do the numbers say?

• The freshest number on the panel is the one an incident commander stares at, so it is exactly the number that must never double-count. Crash-and-replay is the normal case for a stream processor, not the edge case.

5) One marketplace account is in half of all transfers

• Three different hot-account cases hide in this question, and the fused guard is what makes only one of them hard: credits have no guard, debits do.

6) Lifecycle, failure, regions, retention (rapid fire)

• Closing an account with money in it: the remainder transfers to a system escheat account, so conservation holds right through closure.
• Reversals: a refund is a NEW transfer in the opposite direction, reversal_of pointing at the original, never an edit. It runs only under a dedicated service identity with two-person approval and its own audit log, because it is the one path allowed to move money its caller does not own, which makes it the most abuse-sensitive surface in the system.
• Two different PENDINGs: the transfer row's internal PENDING is born and finished inside one transaction, so nobody outside ever observes it. The API's 202 PENDING is the cross-shard or queued state, resolved by polling. The sweeper's whole job is saga intent rows that waited too long; nothing else needs sweeping.
• Primary down: reject transfers immediately. Never queue money you cannot commit. Balances stay readable from replicas, marked stale.
• Kafka down: CDC pauses at the database's own commit log, so nothing is lost; the real limit is WAL disk headroom, so the alert is on space left. Worst case, every derived store rebuilds from the ledger.
• Multi-region: one region owns all writes; a second keeps an always-slightly-behind replica for disaster recovery. True region loss costs at most seconds, reconciled from the replica ledger. Nothing is ever merged.
• Retention: 90 days in the fast database, everything forever in cheap cold storage. The ledger gets point-in-time backups, restore to any minute. Analytics stores are derived and need no backup.
• Numbers watched: transfer p99 and success rate, rejections by reason, analytics freshness p99 under 5s, consumer lag, reconciliation mismatches = 0, replication lag, hot-queue depth.
• Simplest-design honesty: at 1.2K/s the right first system is one Postgres primary plus a one-minute SQL rollup. The streaming tier was bought by one requirement, and name which: the checker's seconds-level detection, not analytics.

Final Design

• One sentence first: every movement of currency, minting and destroying included, is a transfer between accounts in one append-only double-entry ledger, and everything else is derived from it.
• The money path is one guarded ACID transaction: idempotency anchor, two single-row locks in explicit sorted order, the fused floor guard, two legs with balance_after and sequence, and a commit for either outcome. The floor column makes players (0) and faucets (-budget) the same mechanism.
• CDC feeds one stream to two consumers: idempotent SET-from-state rollups for analytics, and the continuous integrity checker holding the freeze lever. The dashed arrow back to the gateway is the argument the whole streaming tier was bought for.
• Cross-shard transfers and the hot-sender queue share the 202 PENDING contract and stay deferred until measurement demands them. The saga's fence is a single-shard outcomes table, never a distributed transaction, and the hot batch locks all touched rows in one global sorted sequence.
• Behind the stream: nightly recompute over hot plus cold tiers, a DR replica region that never merges, and point-in-time backups for the one store that is the truth.

What is Expected at Each Level

• Mid-level candidates are expected to produce double-entry with two legs summing to zero, a guard that lives in the database rather than the app, idempotency keys on the money endpoint, and some reconciliation story.
• Senior candidates are expected to make exactly-once precise: two single-row SELECT FOR UPDATE statements in explicit sorted order (and why ORDER BY + FOR UPDATE is not that), rejection that commits its own anchor, idempotency scoped to (actor, key) with a 409 on body mismatch, CDC instead of dual writes, and SET-from-state rollups defended with the crash-3-seconds-after-checkpoint trace.
• Staff candidates are expected to open with the scale math that says one primary suffices and then name what the streaming tier was actually bought for; to unify overdraft and minting under one floor guard; to argue why MIN(player balance) ≥ 0 is not redundant; to fence the saga with a local outcomes table and write the receiver-shard transaction on request; to split the hot-account question into three cases and catch the batch lock-order deadlock in their own design; and to volunteer the residual honesty themselves: the PENDING status lag during settlement, the outcomes-table TTL, and the faucet replenishment cadence, before the interviewer finds any of them.