Katkat
Back

Design a Cryptocurrency Trading System with Third-Party Exchanges

CoinbaseSoftware Engineer · Onsite
HardSoftware EngineerOnsiteSystem Design

Last updated

This interview question evaluates requirements, scale assumptions, API/data design, architecture, trade-offs, failure modes, and rollout in a realistic interview setting. A strong answer for Design a Cryptocurrency Trading System with Third-Party Exchanges states assumptions, handles edge cases, explains trade-offs, and shows how to validate the result clearly.

Question

Design a cryptocurrency trading platform that routes client orders to one or more third-party exchanges that expose a (nominally) synchronous HTTP order/cancel API. Even though the venue API looks synchronous, fills and cancellations are effectively asynchronous and arrive later via polling, webhooks, or streams.

Address the following:

  1. Overall architecture. Lay out the services, databases, messaging/event bus, and per-exchange connectors. Explain why you offer the client a fast synchronous "accepted" response while real execution happens asynchronously behind the scenes, and how you decouple order submission from fills/cancellations.
  2. Order lifecycle / state machine. Define the full state-transition diagram for an order (e.g., NEW → PENDING_SUBMISSION/PARTIALLY_FILLED → FILLED / CANCELED / EXPIRED / REJECTED, plus an explicit "unknown outcome" state). Specify the allowed transitions, how you persist and recover state, and how you keep transitions idempotent.
  3. Timeouts, partial failures, and exactly-once effects. Explain how the system detects and recovers from third-party exchange timeouts or failures using retries, idempotency keys / client order IDs, deduplication, circuit breakers, dead-letter queues, and reconciliation. Describe how you avoid double execution and approximate exactly-once external effects.
  4. Spiky traffic. Propose strategies (rate limiting, queueing, backpressure, autoscaling, batching, circuit breakers, hot-shard mitigation) to absorb bursty load and protect both your own services and the downstream exchanges' published rate limits.
  5. Data consistency & durability. Specify the consistency and durability guarantees for orders, trades/fills, and user balances (e.g., a double-entry ledger with reserve → settle/release), and how internal strong consistency coexists with eventual consistency against the exchange's truth.
  6. Multi-exchange routing (optional). If a single parent order can be split across venues, describe the smart order router (SOR), parent/child order modeling, and how child fills aggregate into the parent state.
  7. Client APIs, SLAs, and observability. Define the client-facing REST/streaming APIs, target SLAs/SLOs, and the metrics, tracing, logging, and alerting needed to operate the system.