Design an ATM Machine System

An ATM feels like a simple vending machine for cash: insert card, enter PIN, take money. But behind that 30-second interaction sits a distributed system that must guarantee every dollar withdrawn is persisted before the cash dispenser opens, authenticate users via mutual TLS over untrusted networks, and remain available at 99.99% even when backend databases fail.

Functional

• Authentication via card and PIN with MFA: Users log in with a physical card and PIN. The system issues a short-lived auth token and refresh token. The card is the first factor, the PIN is the second; no transaction proceeds without both.
• Core transactions: Withdraw cash, deposit cash or checks, check balance, and transfer funds between accounts. Each operation maps to a distinct API endpoint with its own validation logic.
• Transaction limits and history: Daily and weekly withdrawal caps enforced per account. Transaction history stored with pending/completed/failed status. Old transactions archived regularly since users typically need only recent history.
• Multi-language support and user preferences: The ATM interface supports multiple languages. User preferences (language, preferred default account) are loaded when the card is inserted and remembered across sessions.

ATM systems are surprisingly modest in throughput compared to social media: a network of 10,000 ATMs each handling 300 transactions per day produces only 35 transactions per second at steady state. The engineering challenge is not raw throughput but guaranteeing sub-50ms response times with ACID consistency across geographically distributed machines.

Traffic

ATM network: 10,000 ATMs across the country, each handling roughly 300 transactions per day. That is 3 million transactions per day, or about 35 TPS at steady state.

The ATM's API has two distinct phases: authentication (establishing identity and session) and transactions (operating on accounts). Separating them clarifies security boundaries: authentication validates credentials once, then every subsequent call uses a short-lived token. The critical detail: every transaction API includes an idempotency key, because the ATM will retry on network timeout and a duplicate withdrawal costs a customer real money.

Authentication

Login: POST /api/auth/login

The schema reflects a deliberate decision to split financial data across three separate SQL instances (auth, transactions, and profiles) each sharded by user ID. This seems like unnecessary complexity for 100 TPS, but it enables independent scaling (auth is read-heavy, transactions are write-heavy) and blast-radius isolation (a transaction table issue cannot lock out authentication).

Auth Instance

1CREATE TABLE users (
2user_uid UUID PRIMARY KEY,
3card_number VARCHAR(19) UNIQUE,
4password_hash BYTEA NOT NULL,
5password_salt BYTEA NOT NULL,
6mfa_config JSONB,
7created_at TIMESTAMP DEFAULT NOW()
8);
9- Sharded by user_uid, replicated for read-heavy access

The architecture separates three concerns into distinct service paths: authentication (card and PIN validation), transactions (withdraw, deposit), and preferences (language, settings). Each scales independently because their load profiles differ, auth is read-heavy with small payloads, transactions require ACID writes, and preferences tolerate eventual consistency.

Components

Withdrawal Flow (Critical Path)

This is the most important flow in the system, it moves real money.

SQL-Before-Cache-Before-Response (GATE)

The transaction service looks like a simple CRUD layer, but it carries the system's entire financial correctness burden. Three mechanisms work together: persistence ordering (SQL before cache before response), idempotency keys (preventing duplicate transactions on retry), and row-level locking (preventing overdrafts from concurrent withdrawals).

CP Over AP

Financial data demands strong consistency. The CAP theorem forces a choice during network partitions: serve potentially stale data (availability) or reject requests (consistency). An ATM system chooses consistency, rejecting a withdrawal is far less costly than authorizing one based on a stale balance. The ATM shows "service temporarily unavailable" rather than risk an overdraft.

Separate SQL Instances vs Unified Database

Every component in an ATM system can fail, but financial systems have zero tolerance for data loss. The key insight: failures are acceptable as long as no money moves without a persisted record. The system can be temporarily unavailable, it cannot be temporarily incorrect.

Network Timeout (ATM to Backend)

The current design handles the core ATM use case reliably, but several enhancements would push the system further in security, intelligence, and accessibility.

AI-Powered Fraud Detection

Analyze transaction patterns from Cassandra activity data. Flag unusual locations (ATM in a different city from the user's home), rapid successive withdrawals from different ATMs, or amounts that exceed typical patterns. High-risk transactions require additional verification (re-enter PIN, answer security question) or block automatically. The fraud service runs inline with the transaction path but has strict latency budgets (under 10ms) to avoid degrading user experience.