##### 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.

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.

How do I approach System Design interview questions?

System Design questions require understanding of core concepts and practice. PracHub provides solutions with explanations to help you master system design interviews.

What difficulty level is this interview question?

This is a hard difficulty System Design question, commonly asked during Onsite rounds at Coinbase.

What role is this question designed for?

This question is commonly asked for Software Engineer candidates at Coinbase during technical interviews.

Design a Cryptocurrency Trading System with Third-Party Exchanges

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:

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

Constraints & Assumptions

Preserve the scope, facts, inputs, and requested outputs from the prompt above.
If the prompt leaves a detail unspecified, state a reasonable assumption before relying on it.
Keep the answer interview-ready: concise enough to present, but concrete enough to implement or evaluate.

Clarifying Questions to Ask

Clarify users, core use cases, read/write patterns, scale, latency, availability, and data retention.
State explicit assumptions before making sizing or architecture decisions.
Prioritize the functional path first, then address reliability, security, observability, and rollout.

What a Strong Answer Covers

A scoped requirements summary with concrete non-goals and success metrics.
API, data model, architecture, consistency, capacity, and operations.
Reasoned trade-offs among simple and scalable designs, including bottlenecks and failure modes.
A validation, monitoring, migration, and launch plan appropriate for the risk level.

Follow-up Questions

What breaks first at 10x traffic or data volume?
How would you degrade gracefully during dependency failures?
What metrics and alerts would prove the design is healthy after launch?