How the interviewer opens it
“Design a service that shows the latest stock prices to millions of users around the world in near real time. Cover the path from receiving exchange feeds to updating users' screens.”
The prompt is vague on purpose. The first few minutes are yours: narrow it to the core features and agree on the numbers before you draw anything.
What to clarify first
- price semantics
- upstream scale and recovery
- users and subscriptions
- read:write mix
- latency and intermediate updates
- consistency versus availability
- freshness
- durability
- reconnections and client behavior
- scope boundaries
The answers stay with the interviewer. In a SysRound round, Alex answers them as an interviewer would.
Scope of a strong answer
Core requirements
- Receive exchange price updates and maintain the latest price for each listing
- Return current prices for a user's watchlist and push subsequent changes
- Distribute updates worldwide within the latency target
- Expose stale data and recover correctly after feed, regional, or client disconnections
Usually out of scope
- Order placement, matching engines, and trading-grade execution latency
- Order books, consolidated best bid and offer, and cross-venue price calculation
- Historical charts and permanent tick archives
- Commercial licensing and paid data entitlements; assume users are authorized for the covered feeds
What interviewers probe
- Defining latest across duplicates, gaps, and feed failover
- A later arrival is not necessarily a newer price. Redundant feeds duplicate events, channels lose messages, and feed sessions reset sequence spaces. The internal version must preserve validated source order and remain meaningful in every region after ownership changes.
- Hot-symbol fanout and bounded delivery
- The latest-price state is tiny, but copying changes to 100 million subscriptions dominates the system. A single popular stock can overload a router, and slow screens can turn a healthy stream into an ever-growing queue.
- Snapshot handoff and cross-region reconnect without rollback
- Snapshot reads race with subscriptions. More subtly, a new region can be behind a value the client already displayed. A correct handoff within that region is not enough: the client must preserve a version floor across connections and distinguish catching up from being fresh.
Common mistakes
- Designing a polling API and database while ignoring the much larger push fanout and reconnect load.
- Confusing latest-price display with a lossless trading feed and preserving every tick in every client queue.
- Using arrival order, timestamps, or region-local versions as sufficient proof that a price is newer.
- Treating a healthy socket or an unchanged price as proof of source and regional freshness.
- Missing the snapshot-to-stream race or losing the client's per-instrument version floors on cross-region reconnect.
- Adding a global database write or durable acknowledgement for every individual screen delivery.
The bar by level
- Senior (L5/E5)
- Quantifies fanout and bandwidth, separates source ordering from recipient delivery, handles feed gaps, and gives a correct snapshot-to-stream handoff. Defines versions comparable across regions and preserves client version floors across connections. Walks through a lagging-region reconnect without rollback, with explicit stale status, bounded buffering, hot-symbol fanout, and reconnect admission control.
- Staff (L6+/E6+)
- Establishes source-authority, durable version-continuity, and freshness contracts under fenced ownership and feed-session cutovers. Distinguishes source recovery, regional catch-up, and client catch-up; explains how unchanged instruments become fresh without a new trade. Covers failure boundaries across checkpoints, logs, regions, and retained client state, budgets failure capacity and egress, and separates the display service from a future lossless market-data product.