Banking Database System

Introduction

Banking schemas demand strict ACID, double-entry ledgers, immutable history and audit logs. Mistakes here are headlines.

Understanding the topic

Core concepts to understand:

• Accounts + customers.
• Transactions table — append-only.
• Double-entry: every transfer = two ledger rows summing to zero.
• Daily statements via aggregations.
• Immutable audit log of every change.

Syntax reference

Visual workflow / architecture:

accounts ──▶ ledger_entries (append-only)
                  ▲
transfers ────────┘ (one row creates two ledger entries)
audit_log ─ records who did what, when

Real-world use

Banks, neobanks (Revolut, Mercury, Wise) and Stripe's ledger all use this exact pattern.

Best practices

• Append-only ledger; never update or delete.
• Serializable isolation for transfers.
• Reconcile balances daily.

Hands-on exercise

Interview preparation — practice these questions:

• Q1. Why double-entry?
• Q2. Atomicity in transfers.
• Q3. Reconciliation strategy.
• Q4. Why never UPDATE a ledger row?
• Q5. Isolation level for transfers.