Design core bank operations

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 core bank operations states assumptions, handles edge cases, explains trade-offs, and shows how to validate the result clearly.

Design a BankSystem Class (Take‑home Project)

Goal

Design and document a BankSystem class that supports three operations:

createAccount(timestamp, customerId) -> bool
deposit(timestamp, customerId, amount) -> int
pay(timestamp, sourceAccountId, targetAccountId, amount) -> int

Assume this is an in-memory service intended for correctness and clarity (not persistence or distributed systems).

What to Produce

Provide a complete specification and design that covers:

Data Models

Define the core entities (e.g., Account, Transaction) and their fields.
Specify how balances and transaction records are stored and updated.

Identifier Semantics

Clarify what customerId and accountId represent and how they relate (e.g., 1:1 vs. 1:many).
Reconcile that deposit takes customerId while pay uses accountIds.

Validation Rules

Duplicate vs. nonexistent accounts.
Nonpositive amounts (zero or negative).
Insufficient funds for payments.
Any other constraints you deem important (e.g., overflow, same source/target).

Return Values

Define exactly what the bool and int returns mean in all cases (success and error).
If using error codes, enumerate them.

Data Structures

Describe the primary data structures (e.g., hash maps keyed by accountId) used to implement O(1) operations.

Operational Semantics

For each API, describe step-by-step how state changes and transaction records are appended.
Include how timestamps are used in records.

Complexity

Time and space complexity for each operation and overall storage.

Assumptions

State any reasonable assumptions you make (e.g., single-threaded, amounts in cents, integer timestamps).

You may include concise pseudocode to illustrate the implementation.

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?

Design core bank operations

Quick Overview