Design a Stock Exchange
Match buy and sell orders in microseconds, in a strict and provable order, never lose a fill, and stay correct when the matching engine dies mid-trade.
4 questions on this site are reported in Coinbase software engineer interviews. Each has a full reference design (requirements, back-of-envelope numbers, components, user flows and deep dives with interviewer follow-ups). Each one can be walked through turn by turn and then sat as a mock. Patterns covered: order-book, determinism, event-sourcing, low-latency, fairness, ledger, sharding, hot-keys, fraud, fintech, feature-store, stream-processing, exploration, market-data, order-management, websockets.
Run an AI mock Coinbase interview →One of these questions, run as a live round in that style, with a debrief at the end.
Attribution comes from public interview guides and candidate reports, not from Coinbase. It indicates where a question has been asked, nothing more.
Match buy and sell orders in microseconds, in a strict and provable order, never lose a fill, and stay correct when the matching engine dies mid-trade.
80 M users paying friends instantly: 15 M transfers a day on a sharded double-entry ledger, funded and cashed out over slow bank rails.
Allow, block or challenge 10,000 card payments a second in under 100 ms, then learn from chargebacks that arrive months later.
A retail brokerage: live prices to 3 M phones, 20 k orders a second at the open, every share and cent exact.
60 minutes on the architecture of a real-world service. The example Coinbase gives is a Twitter feed, and candidates also report money-shaped prompts: a ledger, a real-time crypto price service, order routing or scheduled payments.
Going deep on one part too early. Coinbase advises keeping the design general across the whole problem unless the interviewer asks for depth, and checking with them before you finish whether anything is left to cover.
From public interview guides and candidate reports, and Coinbase’s own interview guidance where it publishes any. Not endorsed by Coinbase. Formats change; treat it as a prior, not a promise.
Large-company loops run 45 to 60 minutes, expect numbers, and spend most of the time on deep dives. Walk through a question to see how a strong candidate paces the hour, sit the same question as a mock until you can produce the requirements, the estimates and the design without looking, then read the interview framework guide for how to structure the hour. The other questions on the site teach patterns that show up in Coinbase interviews under different names.
Questions reported in Coinbase system design interviews include Stock Exchange, Venmo, Fraud Detection System and Robinhood. Between them they test order book, determinism, event sourcing, low latency, fairness and ledger. The reports come from public interview guides and candidate accounts, not from Coinbase, so practise the patterns rather than memorising one list.
60 minutes on the architecture of a real-world service. The example Coinbase gives is a Twitter feed, and candidates also report money-shaped prompts: a ledger, a real-time crypto price service, order routing or scheduled payments.
Reports say the Coinbase round weighs 4 things. 1. Clarifying questions: the brief is short, and pinning down the requirements is up to you. 2. The whole problem covered at a general level, naming a technology you know well where it fits. 3. Correctness where money moves: idempotency, no lost or duplicated funds, and reconciliation. 4. Security and consistency around balances, wallets and withdrawals. Going deep on one part too early. Coinbase advises keeping the design general across the whole problem unless the interviewer asks for depth, and checking with them before you finish whether anything is left to cover.
Practise the questions reported there out loud, under a 45-minute clock: requirements with numbers first, then estimates, a high-level design, and deep dives into the two or three hardest parts. Start with Stock Exchange: watch a strong candidate answer it turn by turn, then sit it yourself. Then cover the patterns the round leans on (order book, determinism, event sourcing and low latency) with one more question each.