Katkat
Back

Design a scalable banking system

MetaSoftware Engineer · Technical Screen
HardSoftware EngineerTechnical ScreenSystem Design

Last updated

This problem tests your ability to design a distributed, high-concurrency ledger system that maintains strict consistency and atomicity for financial transactions.

Problem Statement

Design a global, scalable banking ledger system that allows users to transfer funds between accounts. The system must process millions of transactions per day while ensuring zero data loss and strict consistency (no 'double spending').

Requirements

  1. Functional Requirements:
    • Users can check their account balance.
    • Users can transfer funds to another user.
    • The system must support transaction history queries.
  2. Non-Functional Requirements:
    • Consistency: The system must adhere to ACID properties. Money cannot be created or destroyed during a transfer.
    • Scalability: Support a high volume of concurrent transactions.
    • Durability: All completed transactions must be persistent and never lost.
    • Availability: High availability for balance checks and transfers.

What to Cover

  • API Design: Define the interface for transferring funds and querying balances.
  • Data Model: Choose an appropriate database schema. Explain why you chose relational vs. NoSQL or how you ensure atomicity across accounts.
  • Architecture: Provide a high-level design, including service boundaries, message queues, or distributed consensus mechanisms.
  • Handling Concurrency: Explain how you prevent race conditions (e.g., two concurrent transfers reducing a balance below zero).
  • Failure Modes: How do you handle a system crash in the middle of a transfer?

Hints

Hint 1

Consider the 'double-entry bookkeeping' principle where every transaction is recorded as both a debit and a credit in a ledger.

Hint 2

Think about how distributed transactions (e.g., Two-Phase Commit or Sagas) can be used to handle transfers that might span different database shards.

Hint 3

Discuss pessimistic versus optimistic locking strategies for account balances to manage concurrent updates.

Follow-up questions

  • How would you handle a situation where a transfer succeeds in one account but fails in another due to a network partition?
  • If this system needs to generate end-of-day financial reports for millions of users, how would you design the analytical processing layer without slowing down real-time transactions?
  • How would you implement rate limiting and fraud detection to prevent malicious account exhaustion?