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)
-
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