System Design Interview
Real-time sports scores, built up in 4 stages: ingest official partner feeds in order and exactly once, serve 80K reads/s through a CDN and cache, push every goal to fans' screens in under a second over live connections, then harden with dead-letter retries, monitoring and multi-region failover — 22 components at the final stage, each stage sized for more than 2× headroom. A teaching design inspired by live-score services, not any one company's internal architecture.
Build a reliable ingest path with ordering, dedupe, and a durable event log you can replay.
What was missing: Everything starts with getting the score in correctly. Before fans can see anything, we need a reliable way to accept events from official data partners — in order, exactly once, and without ever losing one.
Why that's risky: Without a durable, ordered log, a crash or a partner resending the same event could lose a goal or count it twice — and there would be no way to rebuild the correct score afterwards.
What gets added: A separate partner entry point (mutual TLS + firewall), per-partner rate limits, an Ingestion Service that dedupes and checks sequence numbers, a Match Event Stream partitioned by match, a single-writer Match State Builder, the Snapshot DB (current score per match) and a permanent Event Archive.
Trade-offs: Event sourcing (storing every event, not just the latest score) costs storage and adds a step before the score updates — in return you get replay, audit, and easy correction of mistakes.
Serve millions of reads safely using CDN + cache; keep DB off the critical fan traffic path.
What was missing: Fans can't read the score yet. 80K requests per second during a final would crush any database if every request reached it.
Why that's risky: During a big match everyone asks for the same few scores at the same moment — a classic 'hot key' that can overload a single cache node or database row.
What gets added: A CDN that micro-caches each match's score for 1 second, an API Gateway with rate limits, a stateless Score API, and a Redis Score Cache that the State Builder refreshes on every change.
Trade-offs: A 1-second CDN cache means a fan who only refreshes the page may see a score up to 1 second old — fine for page loads, and the live connection in the next stage removes even that delay.
Fan out ordered deltas to connected clients using realtime gateways and a pub/sub layer.
What was missing: Fans have to keep refreshing to see new goals. Polling from 800K devices is wasteful and still feels slow.
Why that's risky: Polling creates thundering herds (everyone refreshing at once after a goal) and still delivers updates late.
What gets added: Realtime Gateways holding WebSocket / SSE connections behind their own load balancer, a Delta Pub/Sub with one channel per match, and a Notification Worker that sends push alerts for big moments via APNs/FCM.
Trade-offs: Long-lived connections need many gateway servers and careful reconnect handling (jittered backoff), but deliver goals to screens in under a second.
Make the system resilient: retries/DLQ, observability, and multi-region failover for big matches.
What was missing: Operational safety: handling bad partner data and failed deliveries, visibility into what is happening, historical stats, and surviving a whole region going down.
Why that's risky: During a final, one malformed partner event or a stuck consumer could freeze updates for everyone — and without monitoring nobody would notice until fans complain.
What gets added: A Dead-Letter Queue with a Retry Worker (poison-pill events and failed publishes are set aside and retried instead of blocking the match), Observability tracking the key SLOs, and a Stats & History DB built from the stream.
Trade-offs: Two active regions roughly double infrastructure cost and require careful handling of which region 'owns' a match's writes — worth it for events watched by millions.
Write compensating events with higher sequence/version; consumers rebuild snapshots; clients receive correction deltas.
Validate at ingestion, quarantine failures into a DLQ, and use delayed retries with alerting. Keep the stream moving by skipping/isolating bad partitions and replay once fixed.
You're in the middle of an interview session. Leaving now will end your current attempt.
Explore concept overviews, real-system examples, key tradeoffs, and interview talking points for each roadmap section.
You've conquered this phase. These are the skills you now own:
