Design a Distributed Banking Ledger System

Double-Entry Transaction Posting

Next we walk through each box on the diagram. Starting with the posting service, every financial event must produce balanced entries in one ACID transaction.

The posting service is the choke point: each request must produce a self-balanced set of entries, update materialized balances atomically, and emit an audit event, all within a single transaction. Reads scale via nightly snapshots; writes scale via sharding and monthly partitions.

Unlike a consumer wallet in Digital Wallet System where the interview centers on P2P sagas and idempotency keys, banking interviews probe whether you understand institutional bookkeeping: every posting must balance per currency, map to the correct GL account, and leave an immutable audit trail regulators can replay.

Every financial event creates balanced entries:

Transfer $500 from Account A to Account B:
  Entry 1: { account: A, type: DEBIT,  amount: 500.00, tx_id: "txn-123" }
  Entry 2: { account: B, type: CREDIT, amount: 500.00, tx_id: "txn-123" }
  SUM = -500 + 500 = 0 ✓

Atomic posting (PostgreSQL transaction):
  BEGIN;
    INSERT INTO ledger_entries ... VALUES (debit), (credit);
    UPDATE account_balances SET balance = balance - 500 WHERE account_id = 'A';
    UPDATE account_balances SET balance = balance + 500 WHERE account_id = 'B';
    SELECT balance FROM account_balances WHERE account_id = 'A';
    -- If balance < 0 AND account requires non-negative: ROLLBACK
  COMMIT;

Balance Computation: Running Balance vs Calculated

The ledger entries table is the source of truth; account_balances is a performance cache updated in the same transaction as each posting. Summing all entries for a 10-year-old account on every balance query is O(n) and unusable at 100K reads per second; production systems maintain a running balance per account and reconcile nightly against a full recompute.

Approach 1: Calculated (sum all entries) - slow for old accounts
Approach 2: Running balance in separate table - O(1), < 1ms
Approach 3: Periodic checkpoint + delta - nightly batch

We use Approach 2 (running balance) for real-time + Approach 3 for reconciliation.

Immutability: How to "Fix" Errors

Regulators require an append-only audit trail with no UPDATE or DELETE operations on ledger rows, ever. When an entry is wrong, the correction is itself a new posting: a reversal entry that negates the original, followed by the correct entry. The full history remains intact for auditors to replay.

Entry is wrong. Cannot UPDATE or DELETE. How to correct?
Reversal: post a new entry that reverses the original.

Original (wrong): Charged $50 fee instead of $5
  Entry 1: { acct: customer, DEBIT, $50 }
  Entry 2: { acct: fee_rev,  CREDIT, $50 }

Reversal:
  Entry 3: { acct: customer, CREDIT, $50, reverses: entry_1 }
  Entry 4: { acct: fee_rev,  DEBIT, $50, reverses: entry_2 }

Correct posting:
  Entry 5: { acct: customer, DEBIT, $5 }
  Entry 6: { acct: fee_rev,  CREDIT, $5 }

Chart of Accounts and Trial Balance

Banks organize accounts into a chart of accounts (COA): assets, liabilities, equity, revenue, expense. Each account has a type that determines normal balance (assets/expenses debit-normal; liabilities/revenue credit-normal). A trial balance proves the books close: for each currency, SUM(debits) = SUM(credits) across all accounts. Run hourly in production; daily export for finance close.

Chart of accounts (simplified):
  1000: Customer deposits (liability)
  2000: Suspense: cross-shard transfers (asset)
  4000: Fee revenue (revenue)
  5000: Operating expenses (expense)

Trial balance check (hourly cron):
  SELECT currency,
         SUM(CASE WHEN entry_type='debit'  THEN amount ELSE 0 END) AS total_debits,
         SUM(CASE WHEN entry_type='credit' THEN amount ELSE 0 END) AS total_credits
  FROM ledger_entries
  WHERE posted_at >= NOW() - INTERVAL '1 hour'
  GROUP BY currency
  HAVING total_debits != total_credits;  -- must return 0 rows

Cross-Ledger Settlement and Regulatory Close

Large banks run multiple internal ledgers (retail, corporate, card network). Inter-company transfers post to suspense accounts on each ledger; a nightly settlement batch nets positions and posts clearing entries. Month-end close freezes postings to prior periods; corrections use reversing entries dated in the current period. Audit export API returns immutable entry streams by account and date range for 7+ years.

Cross-ledger transfer (retail → card network):
  Retail ledger:  DEBIT customer:alice $100, CREDIT suspense:outgoing $100
  Card ledger:    DEBIT suspense:incoming $100, CREDIT network:settlement $100

Nightly settlement nets suspense balances to zero across ledgers.
Regulatory export: SELECT * FROM ledger_entries WHERE account_id IN (...)
  AND posted_at BETWEEN '2019-01-01' AND '2026-03-14' ORDER BY posted_at;