Banking System Design: A Complete Interview Guide

Before We Start: How to Use This Guide

1. If you're preparing for interviews: Read everything. Understand the "why" behind each decision. Interviewers don't want you to memorize schemas—they want to see you think.
2. If you're new to system design: Don't worry about understanding everything at once. Read it like a story. The concepts will click as you go.

Chapter 1: Understanding What We're Building

What Does a Bank Actually Do?

Banking system diagram 1

Why Banking Systems Are Different

Scale: How Big Is Banking DB?

Banking system diagram 2

• 10 million daily transactions = ~115 transactions per second on average
• But on salary day (1st of month) = 1000+ transactions per second
• During Diwali/festivals = Even higher peaks
• We must design for the peak, not the average

Chapter 2: The Data - What Do We Need to Store?

Think Like a Bank Manager

• Their name, address, phone number
• Their ID proof (PAN, Aadhaar)
• When they joined the bank
• Are they a good customer or risky?

• Account number
• Whose account is it?
• How much money is in it?
• What type of account (savings, current)?
• Which branch handles it?

• What happened (deposit, withdrawal, transfer)?
• How much money?
• When did it happen?
• What was the balance before and after?

Chapter 3: Database Tables - Every Table Explained

Table 1: Customers - The People

Banking system diagram 3

sql
CREATE TABLE customers (
    -- Primary identifier - the computer's way to find you
    customer_id         BIGSERIAL PRIMARY KEY,

    -- Human-readable identifier - what you see on your passbook
    customer_number     VARCHAR(20) NOT NULL UNIQUE,

    -- Basic information
    first_name          VARCHAR(100) NOT NULL,
    middle_name         VARCHAR(100),
    last_name           VARCHAR(100) NOT NULL,
    date_of_birth       DATE NOT NULL,

    -- Sensitive information (encrypted/hashed)
    pan_number_encrypted BYTEA,          -- Encrypted, not plain text
    aadhaar_hash        VARCHAR(64),      -- Only hash, cannot reverse

    -- Contact (needed for OTP, alerts)
    phone_primary       VARCHAR(15) NOT NULL,
    email               VARCHAR(255),

    -- Status tracking
    status              VARCHAR(20) DEFAULT 'ACTIVE',
    kyc_status          VARCHAR(20) DEFAULT 'PENDING',
    risk_category       VARCHAR(20) DEFAULT 'NORMAL',

    -- Audit trail (who created, when modified)
    created_at          TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    updated_at          TIMESTAMP DEFAULT CURRENT_TIMESTAMP,

    -- Soft delete (never actually delete customer data)
    is_deleted          BOOLEAN DEFAULT FALSE
);

-- Why these indexes?
-- Finding customer by phone (login, OTP verification)
CREATE INDEX idx_customers_phone ON customers(phone_primary);
-- Finding customer by name (branch staff search)
CREATE INDEX idx_customers_name ON customers(last_name, first_name);

Table 2: Accounts - Where Money Lives

Banking system diagram 4

You have ₹10,000 in your account.
You deposit a cheque for ₹5,000.
The cheque takes 2 days to clear.

Balance: ₹15,000 (total money, including pending cheque)
Available Balance: ₹10,000 (money you can actually withdraw TODAY)
Hold Amount: ₹5,000 (the pending cheque)

Formula: Available Balance = Balance - Hold Amount

Time 0: Your balance is ₹1000
Time 1: ATM in Mumbai reads balance = ₹1000
Time 2: ATM in Delhi reads balance = ₹1000
Time 3: Mumbai ATM withdraws ₹800, sets balance = ₹200
Time 4: Delhi ATM withdraws ₹800, sets balance = ₹200

Problem: You withdrew ₹1600 from ₹1000 account!

Time 0: Balance = ₹1000, Version = 1
Time 1: Mumbai reads: Balance = ₹1000, Version = 1
Time 2: Delhi reads: Balance = ₹1000, Version = 1
Time 3: Mumbai updates: "SET balance = 200 WHERE version = 1"
        Success! Version becomes 2
Time 4: Delhi updates: "SET balance = 200 WHERE version = 1"
        FAILS! Version is now 2, not 1
        Delhi ATM says "Please try again"

sql
CREATE TABLE accounts (
    -- Identifiers
    account_id          BIGSERIAL PRIMARY KEY,
    account_number      VARCHAR(20) NOT NULL UNIQUE,

    -- Relationships
    customer_id         BIGINT NOT NULL REFERENCES customers(customer_id),
    branch_id           INT NOT NULL REFERENCES branches(branch_id),
    account_type_id     INT NOT NULL REFERENCES account_types(account_type_id),

    -- Money tracking (DECIMAL for exact precision - never use FLOAT for money!)
    balance             DECIMAL(18,2) NOT NULL DEFAULT 0.00,
    available_balance   DECIMAL(18,2) NOT NULL DEFAULT 0.00,
    hold_amount         DECIMAL(18,2) NOT NULL DEFAULT 0.00,
    minimum_balance     DECIMAL(18,2) NOT NULL DEFAULT 0.00,

    -- Interest (for savings accounts)
    interest_rate       DECIMAL(5,4),  -- 0.0350 = 3.5%

    -- Limits (fraud prevention)
    daily_withdrawal_limit  DECIMAL(18,2) DEFAULT 100000.00,
    daily_transfer_limit    DECIMAL(18,2) DEFAULT 500000.00,

    -- Status
    status              VARCHAR(20) DEFAULT 'ACTIVE',

    -- THE CRITICAL VERSION FIELD
    version             INT NOT NULL DEFAULT 1,

    -- Timestamps
    opened_at           TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    updated_at          TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

-- Why DECIMAL(18,2)?
-- 18 total digits, 2 after decimal
-- Maximum: 9,999,999,999,999,999.99 (nearly 10 quadrillion)
-- Enough for any bank balance, with paisa precision

Table 3: Transactions - The Money Movements

Banking system diagram 5

Transaction 1: Deposit ₹1000
  balance_before: 0
  balance_after: 1000

Transaction 2: Withdraw ₹500
  balance_before: 1000
  balance_after: 500

Transaction 3: Transfer ₹200
  balance_before: 500
  balance_after: 300

1. Instant balance history: You can see balance at any point in time
2. Error detection: If balance_after of Txn 2 ≠ balance_before of Txn 3, something is wrong
3. Audit proof: Regulators can verify every rupee movement

sql
-- Partitioned by month
CREATE TABLE transactions (
    transaction_id      BIGSERIAL,
    account_id          BIGINT NOT NULL,
    amount              DECIMAL(18,2) NOT NULL,
    direction           CHAR(1) NOT NULL,  -- 'C' or 'D'
    balance_before      DECIMAL(18,2) NOT NULL,
    balance_after       DECIMAL(18,2) NOT NULL,
    transaction_type    VARCHAR(50) NOT NULL,
    channel             VARCHAR(20) NOT NULL,
    status              VARCHAR(20) DEFAULT 'COMPLETED',
    description         VARCHAR(500),
    reference_number    VARCHAR(50),
    created_at          TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
    ip_address          INET,

    PRIMARY KEY (transaction_id, created_at)
) PARTITION BY RANGE (created_at);

-- Create partitions for each month
CREATE TABLE transactions_2024_01 PARTITION OF transactions
    FOR VALUES FROM ('2024-01-01') TO ('2024-02-01');
CREATE TABLE transactions_2024_02 PARTITION OF transactions
    FOR VALUES FROM ('2024-02-01') TO ('2024-03-01');
-- ... and so on

Banking system diagram 6

Table 4: Ledger Entries - The Accountant's Double-Entry

Banking system diagram 7

For every debit, there must be an equal credit. The sum of all ledger entries must always be zero.

sql
CREATE TABLE ledger_entries (
    entry_id            BIGSERIAL,
    transaction_id      BIGINT NOT NULL,
    account_id          BIGINT NOT NULL,
    entry_type          CHAR(1) NOT NULL,  -- 'D' for Debit, 'C' for Credit
    amount              DECIMAL(18,2) NOT NULL,
    gl_account_id       INT NOT NULL,       -- General Ledger account
    created_at          TIMESTAMP DEFAULT CURRENT_TIMESTAMP,

    PRIMARY KEY (entry_id, created_at)
) PARTITION BY RANGE (created_at);

-- This query should ALWAYS return 0
-- If it doesn't, something is very wrong
SELECT SUM(CASE WHEN entry_type = 'D' THEN amount ELSE -amount END)
FROM ledger_entries;

Table 5: Audit Logs - The Security Camera

Banking system diagram 8

sql
CREATE TABLE audit_logs (
    audit_id            BIGSERIAL PRIMARY KEY,
    table_name          VARCHAR(100) NOT NULL,
    record_id           BIGINT NOT NULL,
    operation           CHAR(1) NOT NULL,  -- 'I', 'U', 'D'
    old_values          JSONB,
    new_values          JSONB,
    changed_fields      TEXT[],
    user_id             BIGINT,
    ip_address          INET,
    created_at          TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

-- CRITICAL: No one can modify or delete audit logs
REVOKE UPDATE, DELETE ON audit_logs FROM PUBLIC;

json
// Example audit log entry
{
    "audit_id": 12345,
    "table_name": "customers",
    "record_id": 67890,
    "operation": "U",
    "old_values": {"phone_primary": "9876543210", "email": "old@email.com"},
    "new_values": {"phone_primary": "9876543210", "email": "new@email.com"},
    "changed_fields": ["email"],
    "user_id": 100,
    "ip_address": "192.168.1.1",
    "created_at": "2024-01-15 14:30:00"
}

Chapter 4: The Complete Architecture - How Everything Connects

The Big Picture

Banking system diagram 9

Let's Walk Through a Money Transfer

Banking system diagram 10

Why Each Component Exists

Load Balancer - The Traffic Police

Banking system diagram 11

Banking system diagram 12

• Distributes incoming requests across multiple servers
• If one server dies, routes traffic to healthy ones
• Can add more servers during peak times (salary day!)

API Gateway - The Security Guard

Banking system diagram 13

• Send 1 million requests per second
• Crash your servers (DDoS attack)
• Try to brute-force passwords

• Each user gets 100 requests per minute
• Excess requests get rejected with "429 Too Many Requests"

Redis Cache - The Speed Boost

Banking system diagram 14

Banking system diagram 15

• Account balances (read frequently)
• Customer profile data
• Recent transactions (for showing history)
• Session data (login state)

• The actual balance during a transfer (must be from database)
• Anything where consistency is critical

Kafka - The Message Delivery Guy

Banking system diagram 16

Banking system diagram 17

PostgreSQL - The Source of Truth

Banking system diagram 18

• Server A says balance is ₹1000
• Server B says balance is ₹800
• Which one is correct?

• Only PRIMARY knows the real balance
• All writes go there
• No confusion, no conflicts

SYNCHRONOUS REPLICATION:
1. Write to Primary: "Set balance = 5000"
2. Primary forwards to Sync Replica
3. Sync Replica confirms: "I've saved it"
4. Primary confirms to application: "Done!"

If Primary crashes AFTER step 4, Sync Replica has ALL the data.
RPO (Recovery Point Objective) = 0 seconds. No data loss.

ASYNCHRONOUS REPLICATION:
1. Write to Primary: "Set balance = 5000"
2. Primary confirms to application: "Done!"
3. Primary forwards to Async Replicas (later)

If Primary crashes BEFORE step 3, Async Replicas might be missing recent data.
But reads are faster because we're not waiting for confirmation.

Chapter 5: The Transaction Flow - Deep Dive

Step 1: The Request Arrives

go
// What arrives at our API
type TransferRequest struct {
    FromAccountID   int64   // Sender's account
    ToAccountID     int64   // Receiver's account
    Amount          float64 // How much to transfer
    Description     string  // "Payment for dinner"
    IdempotencyKey  string  // Prevents double-processing
}

Step 2: Idempotency Check

1. You click "Transfer ₹5000"
2. Network is slow, no response
3. You click again
4. Now you've transferred ₹10,000!

Banking system diagram 19

go
// Check if we've seen this request before
func checkIdempotency(key string) (*TransferResult, bool) {
    // Look in Redis first (fast)
    result, err := redis.Get("idempotency:" + key)
    if err == nil {
        // We've processed this before! Return cached result
        return deserialize(result), true
    }

    // New request, proceed with processing
    return nil, false
}

Step 3: Lock the Accounts

Time 0: Rahul's balance = ₹10,000
Time 1: Transfer A reads balance = ₹10,000
Time 2: Transfer B reads balance = ₹10,000
Time 3: Transfer A deducts ₹8,000, sets balance = ₹2,000
Time 4: Transfer B deducts ₹8,000, sets balance = ₹2,000 (WRONG!)

Result: Rahul transferred ₹16,000 from ₹10,000 account!

Time 0: Rahul's balance = ₹10,000
Time 1: Transfer A LOCKS account, reads balance = ₹10,000
Time 2: Transfer B tries to lock... WAIT!
Time 3: Transfer A deducts ₹8,000, UNLOCKS
Time 4: Transfer B locks, reads balance = ₹2,000
Time 5: Transfer B says "Insufficient balance!" ✓

Transfer 1: Lock Account A, then Lock Account B
Transfer 2: Lock Account B, then Lock Account A

If they run simultaneously:
- Transfer 1 locks A, waits for B
- Transfer 2 locks B, waits for A
- Both wait forever = DEADLOCK!

go
func lockAccountsForTransfer(fromID, toID int64) {
    // ALWAYS lock the lower ID first
    // This way, everyone follows the same order
    var firstID, secondID int64
    if fromID < toID {
        firstID, secondID = fromID, toID
    } else {
        firstID, secondID = toID, fromID
    }

    lockAccount(firstID)
    lockAccount(secondID)
}

1. Lock Account A first (lower ID)
2. Lock Account B second
3. No deadlock!

Step 4: Verify and Execute

go
func executeTransfer(from, to *Account, amount float64) error {
    // 1. Check balance (inside transaction, with lock held)
    if from.AvailableBalance < amount {
        return ErrInsufficientBalance
    }

    // 2. Check daily limits
    todayTotal := getTodayWithdrawals(from.ID)
    if todayTotal + amount > from.DailyTransferLimit {
        return ErrDailyLimitExceeded
    }

    // 3. Debit sender (with optimistic locking)
    newFromBalance := from.Balance - amount
    result := db.Exec(`
        UPDATE accounts
        SET balance = $1, version = version + 1
        WHERE account_id = $2 AND version = $3
    `, newFromBalance, from.ID, from.Version)

    if result.RowsAffected == 0 {
        // Someone else modified the account!
        return ErrConcurrentModification
    }

    // 4. Credit receiver
    newToBalance := to.Balance + amount
    db.Exec(`
        UPDATE accounts
        SET balance = $1, version = version + 1
        WHERE account_id = $2 AND version = $3
    `, newToBalance, to.ID, to.Version)

    // 5. Create transaction records
    createTransactionRecord(from.ID, amount, "DEBIT", newFromBalance)
    createTransactionRecord(to.ID, amount, "CREDIT", newToBalance)

    // 6. Create ledger entries (double-entry)
    createLedgerEntry(from.ID, amount, "DEBIT")
    createLedgerEntry(to.ID, amount, "CREDIT")

    return nil
}

Step 5: Commit or Rollback

Banking system diagram 20

• Either ALL changes happen
• Or NONE of them happen

• The entire transaction is rolled back
• Sender's money is NOT deducted
• No money is lost or created

Chapter 6: Scaling - Handling 10 Million Transactions

Read Scaling: Add More Replicas

• Check balance (READ)
• View transaction history (READ)
• Transfer money (WRITE)
• Download statement (READ)

Banking system diagram 21

1. Set up new PostgreSQL server
2. Point it to primary
3. It automatically syncs all data
4. Start routing read queries to it

Write Scaling: This is Harder

Banking system diagram 22

Banking system diagram 23

Caching Strategy

Banking system diagram 24

go
// After any account balance change
func afterBalanceUpdate(accountID int64) {
    // Delete from cache
    redis.Del(fmt.Sprintf("balance:%d", accountID))

    // Publish event for other services
    kafka.Publish("balance_changed", accountID)
}

// When reading balance
func getBalance(accountID int64) float64 {
    // Try cache first
    cached := redis.Get(fmt.Sprintf("balance:%d", accountID))
    if cached != nil {
        return cached.(float64)
    }

    // Cache miss - get from database
    balance := db.Query("SELECT balance FROM accounts WHERE account_id = $1", accountID)

    // Store in cache for next time (expires in 5 minutes)
    redis.Set(fmt.Sprintf("balance:%d", accountID), balance, 5*time.Minute)

    return balance
}

Chapter 7: Disaster Recovery - When Things Go Wrong

What Can Go Wrong?

Banking system diagram 25

Multi-Region Setup

Banking system diagram 26

Backup Strategy

Banking system diagram 27

WAL Entry 1: "BEGIN TRANSACTION 12345"
WAL Entry 2: "UPDATE accounts SET balance=5000 WHERE id=100"
WAL Entry 3: "UPDATE accounts SET balance=15000 WHERE id=200"
WAL Entry 4: "INSERT INTO transactions ..."
WAL Entry 5: "COMMIT TRANSACTION 12345"

• Entries 1-3 are incomplete (no COMMIT)
• Recovery process ignores them
• Data returns to pre-transaction state
• No partial transfer!

Point-in-Time Recovery

bash
# Restore to exactly 2:30 PM yesterday
pgbackrest restore \
    --stanza=banking \
    --type=time \
    --target="2024-01-14 14:30:00" \
    --target-action=promote

Chapter 8: Security - Protecting the Money

Defense in Depth

Banking system diagram 28

Encryption

Without TLS: "Transfer ₹5000 to account 12345"
With TLS: "a7f3b2c9e8d4f1a0b5c6d7e8f9..."

Database file without encryption:
"Rahul Kumar, PAN: ABCDE1234F, Balance: 50000"

Database file with encryption:
"7f3a9c2b8e5d1f4a0c6b9d2e5f8a1b4c..."

sql
-- PAN number is encrypted with a different key
-- Even DBAs can't see it without special access
INSERT INTO customers (name, pan_encrypted)
VALUES ('Rahul', encrypt('ABCDE1234F', get_encryption_key()));

Access Control

sql
-- Different roles have different access
CREATE ROLE branch_teller;
GRANT SELECT ON customers, accounts, transactions TO branch_teller;
GRANT INSERT ON transactions TO branch_teller;
-- Tellers can view data and create transactions, but can't modify accounts

CREATE ROLE branch_manager;
GRANT branch_teller TO branch_manager;
GRANT UPDATE ON customers TO branch_manager;
-- Managers can do everything tellers can, plus update customer info

CREATE ROLE fraud_investigator;
GRANT SELECT ON ALL TABLES TO fraud_investigator;
REVOKE SELECT ON employees FROM fraud_investigator;
-- Investigators can see everything except employee data

Row-Level Security

sql
-- Tellers only see accounts from their branch
CREATE POLICY branch_isolation ON accounts
    USING (branch_id = current_user_branch_id());

-- Now even if teller queries "SELECT * FROM accounts",
-- they only see their branch's accounts

Chapter 9: Monitoring - Keeping Watch

What to Monitor

Banking system diagram 29

Alert Rules

yaml
# Alert if transaction success rate drops below 99.9%
- alert: LowTransactionSuccessRate
  condition: success_rate < 99.9%
  duration: 2 minutes
  severity: CRITICAL
  action: Page on-call engineer immediately

# Alert if response time is high
- alert: HighLatency
  condition: p99_latency > 2 seconds
  duration: 5 minutes
  severity: WARNING
  action: Send Slack notification

# Alert if replication is lagging
- alert: ReplicationLag
  condition: lag_bytes > 10MB
  duration: 1 minute
  severity: CRITICAL
  action: Page DBA team

Dashboards

1. Business Dashboard: TPS, success rate, volume
2. Performance Dashboard: Latency percentiles, slow queries
3. Infrastructure Dashboard: Server health, resource usage
4. Database Dashboard: Connections, replication, locks

Chapter 10: Interview Cheat Sheet

When Asked "Design a Banking System"

• "How many users? Transactions per second?"
• "What types of transactions? Domestic only or international?"
• "What's the consistency requirement? Can we show slightly stale balance?"

• Draw Customers, Accounts, Transactions tables
• Explain relationships
• Mention partitioning for transactions

• Idempotency
• Locking (and why order matters)
• Double-entry bookkeeping
• Commit/Rollback

• Read replicas for read scaling
• Sharding for write scaling (mention challenges)
• Caching strategy

• Disaster recovery (multi-region, backups)
• Security (encryption, access control)
• Monitoring (key metrics)

Common Follow-Up Questions

The Gold Standards Checklist

• ACID compliance for all money movements
• Double-entry bookkeeping (debits = credits)
• Optimistic locking (version field)
• Pessimistic locking (FOR UPDATE)
• Idempotency for all write operations
• Partitioned transaction tables
• Immutable audit logs
• Field-level encryption for PII
• Multi-region disaster recovery
• Comprehensive monitoring and alerting

Summary: What We Built

1. Never loses money - ACID transactions, WAL, backups
2. Never creates money - Double-entry bookkeeping
3. Never shows wrong numbers - No eventual consistency for balances
4. Scales to millions - Read replicas, sharding, caching
5. Survives disasters - Multi-region, automatic failover
6. Stays secure - Encryption, access control, audit logs
7. Is observable - Metrics, alerts, dashboards