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 cryptocurrency trading with third-party exchanges

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

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

Quick Overview

Context

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

Design cryptocurrency trading with third-party exchanges

Quick Overview

Design a Multi‑Exchange Crypto Order Router: APIs, State Machine, and Reliability

Context

Requirements

Solution

Comments (0)

Design cryptocurrency trading with third-party exchanges

Quick Overview

Design a Multi‑Exchange Crypto Order Router: APIs, State Machine, and Reliability

Context

Requirements

Solution

Comments (0)