##### 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.

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.

How do I approach System Design interview questions?

System Design questions require understanding of core concepts and practice. PracHub provides solutions with explanations to help you master system design interviews.

What difficulty level is this interview question?

This is a hard difficulty System Design question, commonly asked during Take-home Project rounds at Coinbase.

What role is this question designed for?

This question is commonly asked for Software Engineer candidates at Coinbase during technical interviews.

Design a bank account ledger | Coinbase Interview Question

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:

APIs and data model. Define the core APIs and the underlying schema (accounts, transactions, immutable ledger entries, balance aggregates, holds, idempotency records, outbox events).
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.
Balance and overdraft rules. Enforce balance constraints and configurable overdraft limits; distinguish posted balance vs. available balance (net of holds).
Idempotency and exactly-once processing. Make all write APIs idempotent and ensure exactly-once effects for retries, duplicate requests, and inbound rail events.
Concurrency control. Handle concurrent transfers, race conditions, write skew, and deadlocks (isolation level, lock ordering, optimistic versioning).
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.
Monthly statements. Produce statements (opening balance, line items with running balance, totals, closing balance) and reconcile them against the ledger.
Reconciliation with external payment rails. Integrate ACH/cards/wires with idempotent callbacks, settlement ingestion, returns/chargebacks, and three-way reconciliation.
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).
Scale and consistency. Describe sharding, indexing, read replicas, caching, and multi-region strategy while preserving consistency and auditability.
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.

Question

APIs and data model. Define the core APIs and the underlying schema (accounts, transactions, immutable ledger entries, balance aggregates, holds, idempotency records, outbox events).
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.
Balance and overdraft rules. Enforce balance constraints and configurable overdraft limits; distinguish posted balance vs. available balance (net of holds).
Idempotency and exactly-once processing. Make all write APIs idempotent and ensure exactly-once effects for retries, duplicate requests, and inbound rail events.
Concurrency control. Handle concurrent transfers, race conditions, write skew, and deadlocks (isolation level, lock ordering, optimistic versioning).
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.
Monthly statements. Produce statements (opening balance, line items with running balance, totals, closing balance) and reconcile them against the ledger.
Reconciliation with external payment rails. Integrate ACH/cards/wires with idempotent callbacks, settlement ingestion, returns/chargebacks, and three-way reconciliation.
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).
Scale and consistency. Describe sharding, indexing, read replicas, caching, and multi-region strategy while preserving consistency and auditability.
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.

Design a bank account ledger

Quick Overview

Question

Solution

Submit Your Answer

Design a bank account ledger

Quick Overview

Question

Solution

Submit Your Answer