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