Design cryptocurrency trading with third-party exchanges
Overview
This question evaluates a candidate's competency in designing resilient, consistent multi-exchange trading systems, testing skills in API design, state-machine modeling, asynchronous integration with third-party exchanges, fault tolerance, idempotency, and observability within the System Design domain.
Coinbase
Jul 31, 2025, 12:00 AM
Software Engineer
Onsite
System Design
0
0
Design a Multi‑Exchange Crypto Order Router: APIs, State Machine, and Reliability
Context
You are designing a trading platform that accepts client orders and routes them to multiple third‑party exchanges for execution. Exchanges expose heterogeneous APIs; some claim synchronous order placement, but actual fills/cancels arrive asynchronously. The system must be resilient, consistent, and observable under spiky traffic.
Requirements
-
Client‑facing APIs
-
Define REST APIs for:
- Order placement (with idempotency)
- Order status retrieval (single and list)
- Cancellation (idempotent)
- Optional: client notifications (webhooks/WebSocket)
-
Define REST APIs for:
-
Internal order model and state machine
- States: NEW, PENDING_SUBMISSION, SUBMISSION_UNKNOWN, PARTIALLY_FILLED, FILLED, CANCELED, REJECTED, EXPIRED
- Define allowed transitions and idempotency semantics for each transition
-
Asynchrony modeling
- Despite a partner’s synchronous placement API, fills and cancels are asynchronous
- Explain how to use events, callbacks, and/or polling to model end‑to‑end execution without double execution
-
Failure handling and correctness
- Third‑party timeouts, partial failures, retries
- Exactly‑once semantics end‑to‑end, including de‑duplication and reconciliation
-
Spiky traffic strategies
- Rate limits, queues, backpressure, autoscaling, circuit breakers, bulkheads
-
Data properties and visibility
- Data consistency, durability, idempotency keys and TTLs
- Observability: metrics, logs, traces; auditability
Solution
Login required
Show