Katkat

Design a bank account ledger

CoinbaseSoftware Engineer · Online Assessment

Last updated

A complete take-home system-design walkthrough for a bank account ledger service: APIs and data model, an immutable double-entry ledger for auditability, ACID single-account updates and atomic multi-account transfers, idempotency and exactly-once effects, concurrency control, real-time/as-of/historical balance reads, monthly statements, reconciliation with external payment rails, limits, fraud and dispute handling, plus sharding, replicas, recovery, and monitoring strategies for scale.

Question

Design a bank account ledger service for a fintech app. It must support creating accounts, deposits, withdrawals, transfers between accounts, real-time balance queries, historical/as-of balance queries, transaction history, and monthly statements. Build it on an immutable double-entry ledger so the system is fully auditable. Cover the following:

  1. APIs and data model. Define the core APIs and the underlying schema (accounts, transactions, immutable ledger entries, balance aggregates, holds, idempotency records, outbox events).
  2. ACID semantics and atomicity. Guarantee ACID for single-account updates and atomic multi-account transfers; either all ledger entries for a transaction commit or none do.
  3. Balance and overdraft rules. Enforce balance constraints and configurable overdraft limits; distinguish posted balance vs. available balance (net of holds).
  4. Idempotency and exactly-once processing. Make all write APIs idempotent and ensure exactly-once effects for retries, duplicate requests, and inbound rail events.
  5. Concurrency control. Handle concurrent transfers, race conditions, write skew, and deadlocks (isolation level, lock ordering, optimistic versioning).
  6. Real-time, as-of, and historical reads. Serve real-time balances with read-your-writes guarantees, compute as-of-timestamp balances from the ledger, and paginate transaction history.
  7. Monthly statements. Produce statements (opening balance, line items with running balance, totals, closing balance) and reconcile them against the ledger.
  8. Reconciliation with external payment rails. Integrate ACH/cards/wires with idempotent callbacks, settlement ingestion, returns/chargebacks, and three-way reconciliation.
  9. Limits, fraud checks, and dispute handling. Apply velocity/amount limits and risk checks synchronously before commit, monitor asynchronously, and model the dispute/chargeback workflow (provisional credit, resolution).
  10. Scale and consistency. Describe sharding, indexing, read replicas, caching, and multi-region strategy while preserving consistency and auditability.
  11. Failure handling, recovery, and monitoring. Cover retries, transactional outbox, backups/PITR, balance-rebuild paths, invariant audits, and observability/alerting on financial invariants.

Include a concrete data model, core APIs, the transaction flow, failure handling, and how you would monitor correctness.