Crypto Exchange

A cryptocurrency exchange like Coinbase or Binance: order-book trading across hundreds of coin pairs, wallets for hundreds of coins, deposits + withdrawals to the public blockchain, 24/7 operation. The hard parts: a matching engine that's stricter than a stock exchange (never miss a trade, but also never double-spend); multi-chain wallet management with hot/cold segregation — exchanges that hold everything in hot wallets get catastrophically hacked (Mt. Gox, FTX's neighbors); and deposit detection from blockchain — monitoring 20+ chains' finality rules simultaneously without over-crediting reorg-able transactions. Binance does ~$50B+ daily volume; peak trading is 100K+ trades/sec.

Time budget: 45 min whiteboard. Draw architecture, estimate numbers, discuss tradeoffs.

• +2 Frame custody as the hard part. Matching is "stock exchange with different fee math." Custody + chain ingress are the crypto-specific complexity.
• +2 Name finality per chain. BTC 6 confs, ETH 12 blocks, Solana finalized slots. Shows domain fluency.
• +2 Hot / cold split. Mention the ≤ 5% hot heuristic. Interviewers know this; omitting it suggests you've never operated one.
• +2 Per-pair single-threaded matching. Don't propose "distributed matching engine for throughput." It's wrong + candidates who say it fail hard here.
• +1 Journaling + replay. Every mutation goes to a log before state update. Crash recovery is log replay. Universal pattern.
• +1 Proof of reserves is current. Post-FTX reality; interviewers expect you to know it. Merkle tree of balances + on-chain wallet proofs.

Self-score: tally the points you would have mentioned unprompted. 7+ is interview-ready on this problem.

• No back-of-envelope estimation — jumps straight into components without quantifying scale for Crypto Exchange
• Single point of failure — no replication, failover, or redundancy discussed
• Ignores data model and storage choices — hand-waves the database layer