Design real-time stock price viewer

Quick Overview

This question evaluates system-design competency in building low-latency, high-throughput real-time streaming systems, covering ingestion, normalization, deduplication, aggregation, pub/sub dissemination, and operational resilience.

Design real-time stock price viewer

Company: Coinbase

Role: Software Engineer

Category: System Design

Difficulty: hard

Interview Round: Onsite

Design a system to let clients view real-time stock prices only (no historical queries). Describe ingestion from market data feeds, symbol normalization, deduplication, and aggregation; how you would disseminate updates to clients (e.g., pub/sub, WebSockets vs. long polling); API design and throttling; caching and fan-out; latency and consistency goals; backpressure and delivery semantics; horizontal scaling to millions of concurrent users; fault tolerance, failover, and multi-region deployment; and monitoring, alerting, and testing strategies.

Quick Answer: This question evaluates system-design competency in building low-latency, high-throughput real-time streaming systems, covering ingestion, normalization, deduplication, aggregation, pub/sub dissemination, and operational resilience.

|Home/System Design/Coinbase
Coinbase logo
Coinbase
Sep 6, 2025, 12:00 AM
hardSoftware EngineerOnsiteSystem Design
28
0

System Design: Real‑Time Stock Prices Viewer (No History)

You are designing a real‑time system that lets clients view current stock prices only. No historical queries are supported.

Assume:

  • Real‑time view of last trade price and top‑of‑book (best bid/ask) per symbol.
  • Multiple upstream market feeds (e.g., SIP and/or direct exchange feeds).
  • Millions of concurrent end users with watchlists.

Describe and justify a design that covers:

  1. Ingestion and Processing
    • Ingesting market data feeds (parsing, sequencing, network considerations).
    • Symbol normalization and reference data management.
    • Deduplication and out‑of‑order handling.
    • Aggregation (per‑venue books, cross‑venue top‑of‑book, last trade).
  2. Client Dissemination
    • Transport and pub/sub choices (e.g., WebSockets vs. SSE vs. long polling).
    • Fan‑out strategy and edge distribution.
    • Caching current values for fast snapshots.
  3. API and Controls
    • API design for initial snapshot and live updates.
    • Throttling and quotas (per connection, per symbol, message rates).
  4. Performance and Reliability Goals
    • Latency and consistency targets.
    • Backpressure policy and delivery semantics to clients.
    • Horizontal scaling to millions of concurrent users.
  5. Resilience and Operations
    • Fault tolerance, failover, and multi‑region active/active deployment.
    • Monitoring, alerting, and on‑call runbooks.
    • Testing strategies (including load tests and simulators).

Keep the scope to real‑time only (no historical query capabilities). State reasonable assumptions where needed and explain trade‑offs.

Submit Your Answer to Earn 20XP

Sign in to leave a comment

Loading comments...