Design Crypto Exchange

Designing a Centralized Crypto Exchange

After two decentralized protocols, this question flips the whole problem on its head, and saying so explicitly is the strongest opening: a centralized exchange like Coinbase or Binance is not a blockchain system — it is a low-latency trading and custody business that happens to touch chains at its edges. Almost everything that matters happens off-chain, in a fast in-memory matching engine and a strongly-consistent ledger; the blockchain appears only at two seams, deposits and withdrawals.

The system has three loosely-coupled halves, and an interviewer wants to hear you separate them. First, the matching engine: an in-memory limit order book per trading pair that matches buy and sell orders by price-time priority, at very high throughput and microsecond-to-millisecond latency. This is a classic exchange-design problem and owes nothing to crypto — it is the same shape as a stock exchange. Second, the wallet ledger: a double-entry accounting system tracking every user's available and on-hold balance for every asset, which must be strongly consistent — a bug here is stolen or invented money. Third, custody and chain integration: the deposit pipeline that watches the blockchain and credits users after enough confirmations, and the withdrawal pipeline that signs and broadcasts transactions from hot and cold wallets.

The defining tension is consistency boundaries. Market data — the order book and trade tape streamed to thousands of clients — is naturally an AP, fan-out-heavy, eventually-consistent read problem. Balances and the ledger are the opposite: strict CP, because the system custodies real money and the integrity invariant (the sum of user balances equals what the exchange actually holds on-chain) must never break. A strong candidate draws that line early and designs the two halves differently.

The reason this question separates people is the failure stories, and they are crypto-specific. A chain reorg can credit a deposit twice if you confirm too shallowly. A retried API call can double-withdraw without an idempotency key. The matching engine can race ahead of the ledger and fill an order the user could not actually fund. And a hot trading pair can serialize the whole book under lock contention. Having these ready — and knowing the answers are confirmations, idempotency keys, holds-before-match, and per-symbol sharding — is what proves you have operated a real exchange, not drawn a box diagram.