Design a Crypto Exchange (Centralized)

Problem statement

Design a centralized crypto exchange (CEX) that lists hundreds of trading pairs, accepts limit and market orders in real time, matches them with price-time priority, tracks every user balance across multiple assets, holds customer deposits in a tiered hot/warm/cold wallet architecture, enforces KYC/AML obligations, and survives both technical failure and adversarial attack without losing a single trade or a single satoshi of customer money.

The defining property of this system is that it is simultaneously three things. It is an exchange: a deterministic central limit order book (CLOB) where latency and throughput determine commercial viability. It is a bank: a double-entry ledger where every movement of every asset must balance to zero and reconcile against on-chain omnibus wallets. It is a regulated money services business: KYC onboarding, sanctions screening, Travel Rule transfers, market surveillance, and audit evidence are not features bolted on at the end, they are admission controls on the hot path.

Why the problem is distinctive

A social feed can retry a post. An exchange cannot retry a fill. Money state admits no eventual consistency: if two regions both believe they own the same balance, the result is not a stale UI, it is a double spend of customer funds. Therefore the design separates four planes with different consistency and latency contracts.

1. Trading plane: per-symbol single-writer matching engines, deterministic, journaled, replayable, sub-millisecond internal latency.
2. Money plane: double-entry ledger, strongly consistent per account aggregate, append-only postings, continuous reconciliation.
3. Access plane: REST, WebSocket, and FIX ingress with authentication, rate limits, market-data fan-out, and KYC-gated permissions.
4. Control plane: risk engine, compliance, custody signing ceremonies, release governance, proof-of-reserves, and incident command.

A strong interview answer keeps these planes separate: the matching engine never writes to the ledger synchronously, the ledger never blocks a fill, and the custody signer never trusts an unauthenticated internal request.

Public operating baseline versus design assumptions

Public evidence establishes the category's scale. Coinbase has reported more than 110 million verified users and quarterly trading volume in the hundreds of billions of dollars at peak cycles, and states that roughly 98% of customer assets are held in cold storage. Binance has publicly described matching engine capacity on the order of 1.4 million orders per second. Kraken has operated since 2011 with a PostgreSQL-centric engineering culture and publishes proof-of-reserves attestations. These are cited company figures, not requirements for our fictional system.

For capacity planning this answer explicitly assumes 15 million verified users, 3 million DAU, 400,000 peak concurrent WebSocket sessions, 800 listed markets, 25 million executions per day, and a 20x order-message peak. Unless a number is tied to a citation, it is a stated design assumption, target, budget, or illustrative threshold, not a claim about any company's private architecture.