How the interviewer opens it
“Design a cryptocurrency exchange where customers submit limit orders and trade assets. Customers can view order books, cancel orders, and inspect their balances.”
The prompt is vague on purpose. The first minutes are for you. Reduce the prompt to the core features and agree on the numbers before you draw.
What to clarify first
- Order types and scope
- Trade rules
- Customers and active state
- Write traffic
- Read traffic
- Latency
- Consistency and availability
- Deployment and durability
- Custody boundary
- Retries and cancellation
The interviewer has the answers. In a SysRound round, Alex gives these answers, as a real interviewer does.
Scope of a strong answer
Core requirements
- Submit and cancel spot limit orders
- Maintain order books with price-time priority
- Execute trades without overspending customer assets
- Track available and reserved balances and reconcile custody assets
Usually out of scope
- Margin, leverage, and derivatives
- Market orders and advanced order types
- Trade fees
- Blockchain protocols and private key management
- Market surveillance and identity verification
What interviewers ask about
- Order priority
- Order sequence determines prices and which customer receives a fill. Partial fills and cancellation races must preserve the same trade rules.
- Crash recovery
- A crash can separate command delivery, durable execution, and publication. Duplicate commands can create new trades even when the ledger rejects duplicate fill events.
- Funds across markets
- Several markets share each customer's assets. Partial fills, better prices, and delayed ledger updates change how much money each order still needs.
- Asset conservation
- Trade execution can precede ledger updates. Duplicate events and uncertain custody transfers must not create assets or hide a custody deficit.
Common mistakes
- Describes the order book but omits fund reservations.
- Assigns spendable balances to markets even though customers share assets across markets.
- Deduplicates API requests and ledger events but lets repeated market commands execute again.
- Releases the original reservation after a partial fill or an uncertain cancellation.
- Acknowledges trades before durable commit or permits the old market owner to commit after failover.
- Treats internal ledger balance as proof of custody solvency.
The bar by level
- Senior (L5/E5)
- Connects market sequence, durable command deduplication, reservations, cancellations, and ledger settlement. Explains recovery, cross-market overspending, and delayed balance updates.
- Staff (L6+/E6+)
- Defines commit and ownership boundaries across markets, ledger, and custody. Proves recovery preserves command identities and asset conservation. Justifies partition boundaries, retry retention, and overload limits.