Design and implement a basic online banking system that supports creating accounts, deposits, withdrawals, and transfers between users. Define the data model and APIs, ensure atomicity and idempotency of money movements, prevent double spending under concurrency, maintain an immutable ledger/audit trail, and address security concerns (authentication, authorization, input validation). Discuss consistency guarantees and error handling.

This question evaluates understanding of transactional system design, data modeling for financial domains, API design, idempotency, concurrency control, immutable audit trails, and security considerations in an online banking context.

How do I approach System Design interview questions?

System Design questions require understanding of core concepts and practice. PracHub provides solutions with explanations to help you master system design interviews.

What difficulty level is this interview question?

This is a hard difficulty System Design question, commonly asked during Onsite rounds at Coinbase.

What role is this question designed for?

This question is commonly asked for Software Engineer candidates at Coinbase during technical interviews.

Design a basic banking system | Coinbase Interview Question

System Design: Basic Online Banking with Safe Money Movements

Context

Design a minimal but production-minded online banking service. It must support core money operations while ensuring correctness under retries and concurrency, and provide strong auditability and security.

Assume a single region deployment with a relational database (e.g., PostgreSQL). Currency is fiat (e.g., USD) with integer minor units (cents) to avoid floating point error.

Functional Requirements

Create accounts for users.
Deposit funds into an account.
Withdraw funds from an account.
Transfer funds between accounts.

Non-Functional Requirements

Atomicity: Money movements are all-or-nothing.
Idempotency: Safe client retries without duplicate movements.
Concurrency safety: Prevent double-spend and race conditions.
Immutable ledger/audit trail: Append-only financial records with reversals, not edits.
Security: Authentication, authorization, input validation.
Consistency and error handling: State guarantees and clear error semantics.

Deliverables

Data model (schemas at the level of tables and key fields).
API design (endpoints, key request/response fields, idempotency).
Transaction flow for deposits, withdrawals, and transfers (including concurrency control).
Approach to an immutable ledger and auditability.
Security considerations.
Consistency guarantees and error handling strategy.

Context

Assume a single region deployment with a relational database (e.g., PostgreSQL). Currency is fiat (e.g., USD) with integer minor units (cents) to avoid floating point error.

Non-Functional Requirements

Atomicity: Money movements are all-or-nothing.

Idempotency: Safe client retries without duplicate movements.

Concurrency safety: Prevent double-spend and race conditions.

Immutable ledger/audit trail: Append-only financial records with reversals, not edits.

Security: Authentication, authorization, input validation.

Consistency and error handling: State guarantees and clear error semantics.

Deliverables

Data model (schemas at the level of tables and key fields).

API design (endpoints, key request/response fields, idempotency).

Transaction flow for deposits, withdrawals, and transfers (including concurrency control).

Approach to an immutable ledger and auditability.

Security considerations.

Consistency guarantees and error handling strategy.

Design a basic banking system

Quick Overview

System Design: Basic Online Banking with Safe Money Movements

Context

Functional Requirements

Non-Functional Requirements

Deliverables

Solution

Comments (0)

Design a basic banking system

Quick Overview

System Design: Basic Online Banking with Safe Money Movements

Context

Functional Requirements

Non-Functional Requirements

Deliverables

Solution

Comments (0)