Design a Stock Ticker/Price Feed Service
Design a service to deliver real-time stock price updates to millions of clients. Focus on low latency, connection multiplexing, and fan-out protocols (WebSockets).
Why Interviewers Ask This
Interviewers at Stripe ask this to evaluate your ability to design high-throughput, low-latency systems under extreme scale. They specifically test your understanding of connection multiplexing and fan-out protocols like WebSockets, ensuring you can balance real-time data consistency with the massive concurrency required by financial infrastructure.
How to Answer This Question
1. Clarify requirements: Define latency targets (sub-100ms), update frequency, and client count to set realistic constraints for a Stripe-like environment. 2. Choose the protocol: Explicitly select WebSockets over HTTP polling or Server-Sent Events to justify persistent, bidirectional communication. 3. Design the ingestion layer: Propose a Kafka or Pulsar pipeline to buffer incoming market data before distribution. 4. Architect the fan-out: Detail how to use an in-memory pub/sub system like Redis or NATS to push updates efficiently to millions of connected clients without blocking threads. 5. Address reliability: Discuss reconnection logic, backpressure handling, and message deduplication to ensure no data loss during spikes. 6. Scale considerations: Explain horizontal scaling using sharding strategies based on ticker symbols or geographic regions.
Key Points to Cover
- Explicitly justifying WebSockets over HTTP polling for persistent, low-latency streams
- Describing a Pub/Sub architecture (like Kafka or Redis) to solve the fan-out problem
- Addressing backpressure mechanisms to prevent memory exhaustion during traffic spikes
- Explaining horizontal sharding strategies to distribute load across multiple server instances
- Demonstrating awareness of connection state management and reconnection logic
Sample Answer
To design a stock ticker service for millions of users, I would prioritize low latency and efficient bandwidth usage. First, we must define the SLA: updates should reach clients within 50 milliseconds of exchange executi…
Common Mistakes to Avoid
- Recommending HTTP long-polling which introduces unnecessary latency and connection churn compared to WebSockets
- Ignoring backpressure, leading to a design that crashes when the number of subscribers exceeds server capacity
- Proposing a database lookup for every single update instead of using an in-memory cache for speed
- Failing to discuss how to handle client disconnections and state synchronization upon reconnection
Sound confident on this question in 5 minutes
Answer once and get a 30-second AI critique of your structure, content, and delivery. First attempt is free — no signup needed.