Design a mini banking system

Quick Overview

This interview question evaluates requirements, scale assumptions, API/data design, architecture, trade-offs, failure modes, and rollout in a realistic interview setting. A strong answer for Design a mini banking system states assumptions, handles edge cases, explains trade-offs, and shows how to validate the result clearly.

Design a mini banking system

Company: Meta

Role: Software Engineer

Category: System Design

Difficulty: medium

Interview Round: Technical Screen

Design and implement an in-memory banking system with the following operations: ( 1) createAccount(accountId, initialBalance= 0); ( 2) deposit(accountId, amount); ( 3) transfer(fromId, toId, amount) that debits fromId and credits toId, rejecting the transfer if fromId has insufficient funds. Maintain, for each account, the cumulative outgoing transaction amount (sum of all debits initiated by that account). Then implement topNAccountsByOutgoing(n) that returns the top n accounts by total outgoing amount, breaking ties by accountId ascending. The output should be a list of strings formatted as "{outgoingAmount}:{accountId}". Describe your data structures, error handling (e.g., unknown account, invalid amounts, insufficient funds), and provide pseudocode for both a full-sort solution and a heap-based top-k solution. Analyze time and space complexity.

Quick Answer: This interview question evaluates requirements, scale assumptions, API/data design, architecture, trade-offs, failure modes, and rollout in a realistic interview setting. A strong answer for Design a mini banking system states assumptions, handles edge cases, explains trade-offs, and shows how to validate the result clearly.

|Home/System Design/Meta
Meta logo
Meta
Aug 7, 2025, 12:00 AM
mediumSoftware EngineerTechnical ScreenSystem Design
9
0

Design a mini banking system

In-Memory Banking System — Design and Implementation

You are to design and implement an in-memory banking system that supports account management and transactions, and can report the top-k accounts by their cumulative outgoing transfers.

Operations

  1. createAccount(accountId, initialBalance = 0)
    • Creates a new account with the given ID and initial balance (default 0).
  2. deposit(accountId, amount)
    • Adds funds to an existing account.
  3. transfer(fromId, toId, amount)
    • Debits the sender (fromId) and credits the receiver (toId).
    • Reject the transfer if the sender has insufficient funds.
    • Maintain, for each account, the cumulative outgoing transaction amount (sum of all successful debits initiated by that account).

Reporting

  • topNAccountsByOutgoing(n)
    • Returns the top n accounts by total outgoing amount, breaking ties by accountId ascending.
    • Output format: a list of strings formatted as "{outgoingAmount}:{accountId}".

Requirements

  • Describe the data structures you will use.
  • Specify error handling for cases such as unknown account, invalid amounts, and insufficient funds.
  • Provide pseudocode for both:
    • a full-sort solution, and
    • a heap-based top-k solution.
  • Analyze time and space complexity for each operation and for both top-k approaches.

Constraints & Assumptions

  • Preserve the scope, facts, inputs, and requested outputs from the prompt above.
  • If the prompt leaves a detail unspecified, state a reasonable assumption before relying on it.
  • Keep the answer interview-ready: concise enough to present, but concrete enough to implement or evaluate.

Clarifying Questions to Ask Guidance

  • Clarify users, core use cases, read/write patterns, scale, latency, availability, and data retention.
  • State explicit assumptions before making sizing or architecture decisions.
  • Prioritize the functional path first, then address reliability, security, observability, and rollout.

What a Strong Answer Covers Guidance

  • A scoped requirements summary with concrete non-goals and success metrics.
  • API, data model, architecture, consistency, capacity, and operations.
  • Reasoned trade-offs among simple and scalable designs, including bottlenecks and failure modes.
  • A validation, monitoring, migration, and launch plan appropriate for the risk level.

Follow-up Questions Guidance

  • What breaks first at 10x traffic or data volume?
  • How would you degrade gracefully during dependency failures?
  • What metrics and alerts would prove the design is healthy after launch?

Submit Your Answer to Earn 20XP

Sign in to leave a comment

Loading comments...