Katkat
Back

Design real-time crypto prices homepage

CoinbaseSoftware Engineer · Onsite
HardSoftware EngineerOnsiteSystem Design

Last updated

This question tests your ability to design a high-throughput, low-latency streaming architecture capable of processing volatile financial data and pushing updates to millions of concurrent users.

Design a Real-Time Crypto Prices Homepage

Design a system that displays live cryptocurrency price updates (e.g., BTC/USD) on a web dashboard. The system must support millions of concurrent users with sub-100ms latency from the time a price update is received from an upstream exchange to the time it reaches the client.

Requirements

Functional Requirements:

  1. Clients can view a list of supported cryptocurrencies and their current market prices.
  2. Prices must update in real-time without the user manually refreshing.
  3. The system should maintain a historical price trend (e.g., the last 24 hours of OHLCV data).

Non-Functional Requirements:

  1. Scale: Handle 5 million concurrent active users.
  2. Latency: End-to-end latency of under 100ms for price updates.
  3. Availability: The system must be highly available; losing an update is acceptable, but system downtime is not.
  4. Consistency: Users should see roughly the same price at any given moment, though minor jitter is acceptable.

Design Expectations

Your response should cover:

  • Data Ingestion: How to handle raw WebSocket/REST streams from multiple global exchanges (Binance, Kraken, etc.).
  • Normalization & Aggregation: How to normalize data from different formats and calculate a unified "Market Price."
  • Fanout Strategy: How to push updates to 5 million users efficiently.
  • Storage: Choice of databases for caching current prices versus long-term historical data.
  • Trade-offs: How you handle high volatility bursts (e.g., a flash crash where volume spikes 100x).

Hints

Hint 1

Consider the difference between a pull-based REST API and a push-based WebSocket strategy for client delivery.

Hint 2

Use a message broker like Kafka to decouple the ingestion tier from the processing and fanout tiers to handle bursts.

Hint 3

Evaluate the use of Redis Pub/Sub or a dedicated edge-caching layer to manage the massive fanout requirement to client connections.

Follow-up questions

  • How would you handle a scenario where one upstream exchange feeds corrupted or highly anomalous price data?
  • If we need to support multi-region deployment, how do you keep the price state synchronized globally?
  • How would you implement a rate-limiting strategy that ensures free users receive updates every 1 second while premium users receive them every 100ms?