PracHub
QuestionsLearningGuidesInterview Prep
|Home/System Design/Coinbase

Design real-time exchange data sync system

Last updated: Mar 29, 2026

Quick Overview

Design real-time exchange data sync system evaluates requirements, scale assumptions, API/data design, architecture, trade-offs, failure modes, and rollout in a realistic interview setting. A strong answer states assumptions, handles edge cases, explains trade-offs, and shows how to validate the result clearly.

  • hard
  • Coinbase
  • System Design
  • Software Engineer

Design real-time exchange data sync system

Company: Coinbase

Role: Software Engineer

Category: System Design

Difficulty: hard

Interview Round: Onsite

Design a system that continuously ingests and syncs stock data from multiple exchanges and renders an always up-to-date web page. Cover data sources (polling vs. streaming), schema normalization, deduplication, handling time zones and out-of-order events, caching and storage, API design, client updates (WebSocket/SSE), consistency and latency targets, fault tolerance and backfill, rate limiting, scaling and partitioning, observability, security, and cost considerations.

Quick Answer: Design real-time exchange data sync system evaluates requirements, scale assumptions, API/data design, architecture, trade-offs, failure modes, and rollout in a realistic interview setting. A strong answer states assumptions, handles edge cases, explains trade-offs, and shows how to validate the result clearly.

Related Interview Questions

  • Design a Real-Time Asset Price Service - Coinbase (medium)
  • Design Crypto Order Routing - Coinbase (hard)
  • Design a crypto trading web frontend - Coinbase (hard)
  • Design query pagination for large datasets - Coinbase (medium)
  • Design real-time crypto prices homepage - Coinbase (hard)
|Home/System Design/Coinbase

Design real-time exchange data sync system

Coinbase logo
Coinbase
Jul 26, 2025, 12:00 AM
hardSoftware EngineerOnsiteSystem Design
5
0

Design real-time exchange data sync system

System Design: Real-Time Multi-Exchange Stock Data Ingestion and Live Web Page

Context

You are asked to design a production system that continuously ingests stock market data from multiple exchanges and renders an always up-to-date web page for users. Data includes trades and quotes (top-of-book), and the system must support historical queries and real-time streaming updates.

Assume: multiple heterogeneous data sources (direct exchange feeds and/or vendor APIs), variable market hours, exchange-specific schemas, intermittent network failures, and strict rate limits.

Requirements

Design the system and cover the following areas:

  1. Data sources
    • Polling vs. streaming criteria and trade-offs
    • Connectors to multiple exchanges/vendors
  2. Schema normalization
    • Canonical symbol mapping and data model for trades/quotes/book updates
  3. Deduplication and idempotency
    • Event identity across venues/providers
  4. Time handling and ordering
    • Time zones, trading sessions, and out-of-order events
  5. Caching and storage
    • Hot cache, time-series storage, long-term archive
  6. API design
    • Historical REST APIs and real-time streaming (WebSocket/SSE)
  7. Client updates
    • Subscription, snapshot + delta model, resumability
  8. Consistency and latency targets
    • SLAs/SLOs, read semantics
  9. Fault tolerance and backfill
    • Retries, DLQs, replays, historical gap filling
  10. Rate limiting
    • Upstream (exchanges) and downstream (clients)
  11. Scaling and partitioning
    • Per-symbol/venue partitioning and horizontal scale
  12. Observability
    • Metrics, logs, tracing, data quality checks
  13. Security and compliance
    • Auth, transport security, secrets, market data entitlements
  14. Cost considerations
    • Storage/compute trade-offs, data retention, egress

State assumptions where needed and justify design choices.

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 Guidance

  • 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 Guidance

  • 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 Guidance

  • 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?

Submit Your Answer to Earn 20XP

Sign in to leave a comment

Loading comments...

Browse More Questions

More System Design•More Coinbase•More Software Engineer•Coinbase Software Engineer•Coinbase System Design•Software Engineer System Design

Your design canvas — auto-saved

PracHub

Master your tech interviews with 9,000+ real questions from top companies.

Product

  • Questions
  • Learning Tracks
  • Interview Guides
  • Resources
  • Premium
  • For Universities

Browse

  • By Company
  • By Role
  • By Category
  • Topic Hubs
  • SQL Questions
  • AI Coding Questions
  • Compare Platforms
  • Discord Community

Support

  • support@prachub.com
  • (916) 541-4762

Legal

  • Privacy Policy
  • Terms of Service
  • About Us

© 2026 PracHub. All rights reserved.