FSD Frontend System Design

Part VI — The Blueprint · Lesson 11.7

HLD – Live Commentary (CricInfo, Cricbuzz)

In one lineOne event fans out to millions of read-only clients — the design problem is broadcast, not interaction.

Where you've seen itA wicket in a World Cup final. Nobody is sending anything; everybody is receiving the same thing at once.

  • Time18 min
  • DiagramFan-out from one event to N clients + the spike profile
  • Chapter11 · High Level Design

Diagram

diagram
1–2 · SCOPE AND SCALE

  in scope   live score · ball-by-ball commentary · scorecard
  out        chat · betting · video · fantasy leagues
  scale      10M concurrent at peak · 1 event every ~30s normally,
             bursts around wickets · traffic 50× baseline in minutes
             READ-ONLY: clients never write
diagram
3 · FAN-OUT — one event, ten million deliveries

                  ┌──────────────┐
                  │ scoring feed │  1 event
                  └──────┬───────┘
                         ▼
                  ┌──────────────┐
                  │   pub/sub    │
                  └──────┬───────┘
              ┌──────────┼──────────┐
              ▼          ▼          ▼
        ┌─────────┐┌─────────┐┌─────────┐
        │ edge PoP││ edge PoP││ edge PoP│   SSE connections held here
        └────┬────┘└────┬────┘└────┬────┘
        ~3M      ~3M       ~4M clients

  SSE (2.5), not WebSocket: clients only receive, and SSE gives
  auto-reconnect and Last-Event-ID replay for free.
diagram
6a · DEEP DIVE — TRANSPORT CHOICE AND FALLBACK

  primary    SSE          one-way · plain HTTP · free reconnect
  fallback   short poll   for proxies that block streaming (2.2)
                          10s interval + ETag → cheap 304s

  degrade under extreme load:
    normal   push every event
    spike    coalesce: one update per 2s carrying the latest state
    extreme  fall back to polling a CDN-cached score.json (TTL 5s)
             ← survives ANY load, because it's just a cached file
diagram
6b · DEEP DIVE — THE SPIKE PROFILE

  concurrent viewers
    ▲
  10M│                    ╭──╮  wicket / last over
    │                    │  │
   5M│         ╭─────────╯  ╰──────╮
    │   ╭─────╯                    ╰────
   1M│───╯
    └────────────────────────────────────► time
      pre-match   innings        finish

  Design for the peak, and make the degraded mode automatic —
  a CDN-cached JSON poll is the floor you can always fall back to.

How it works

  1. SSE per client, terminated at edge PoPs so no single origin holds ten million connections.
  2. Send deltas, not the whole scorecard — a ball event is tiny; the full state is not.
  3. Include a monotonic event id so reconnects resume via Last-Event-ID with no gap (2.5).
  4. Coalesce under load: batch to one update every second or two; nobody perceives the difference.
  5. CDN-cached JSON with a short TTL as the guaranteed fallback — it scales infinitely because it's a static file.

Trade-offs

ChoiceCost
SSENo client→server channel (not needed here)
WebSocketDuplex you don't use, harder scaling
CDN-cached pollingUp to TTL seconds stale; infinitely scalable
Delta eventsClient must hold and patch state correctly

Interview angle

"Ten million concurrent viewers. WebSocket or SSE?"

  • SSE: the traffic is entirely one-way, and reconnect plus replay come free, which is the expensive part of a WebSocket build.
  • Terminate connections at edge PoPs fanning out from pub/sub, so the origin publishes once.
  • Then name the degradation ladder: full push → coalesced push → CDN-cached JSON polling, so peak load has a floor.

Recap

  • Read-only fan-out means SSE, not WebSocket.
  • Send deltas with event ids; reconnect resumes automatically.
  • Always have a CDN-cached polling fallback — it's the only mode that can't be overwhelmed.