An interviewer says - design the delivery path for a live cricket scorecard to a peak concurrent audience of the size Hotstar reported for the 2023 World Cup final, around 59 million. Walk me through the clarifying questions that change the design, then your first architecture.

What the interviewer is testing

Whether you notice that 59 million is not one problem. It is several delivery problems with different economics, and a candidate who starts drawing WebSocket servers has already committed to the most expensive one. The test is whether you can turn an intimidating number into a small number of decisions.

The clarifying questions that change the answer

1. How fresh must the score be? If two seconds of staleness is acceptable, the answer is HTTP polling behind a CDN with a short cache lifetime, and the origin serves a handful of requests per second regardless of audience size. If it must be sub-second and pushed, you need persistent connections, and the cost rises by orders of magnitude. This single question moves the design more than everything else combined.
2. Is the payload identical for everyone? A scorecard is the same for all viewers, so it is cacheable at the edge. If it is personalised - the user's team, their bets, their language - the cache hit rate collapses and the design becomes fan-out per user.
3. What is the write rate? A score changes a few times a minute, not thousands of times a second. Read amplification is the whole problem and write volume is negligible, which points at precomputation and edge caching rather than at a database.
4. Does anything flow back from the client? Chat, reactions or polls turn a broadcast into a bidirectional system with a completely different cost structure.
5. What happens at the spike? Concurrency does not ramp; it steps, when a wicket falls or the match starts. Reactive autoscaling takes minutes and the step takes seconds, so capacity is pre-provisioned or the first minutes are shed.

A strong answer's arc

Start with the cheapest thing that meets the freshness requirement. A static JSON document, regenerated on change, served from a CDN with a one to two second cache lifetime, absorbs essentially all of the 59 million at the edge. Origin load is a function of the number of edge nodes, not of viewers. Then justify each escalation: if sub-second push is genuinely required, add a connection tier with hierarchical fan-out, where a small number of publishers feed regional relays which feed connection servers, so no single node fans out to millions.

Size the expensive path honestly: an idle TLS WebSocket costs roughly tens of kilobytes of kernel and user-space buffers, so a million connections is tens of gigabytes before any application state, and 59 million means thousands of connection servers plus the load balancers and the reconnect storm when one fails.

Common weak answers

• Starting with WebSockets because the word "live" appeared, without asking about freshness. This is the answer the question is designed to catch.
• A pub/sub topic per user, which is tens of millions of subscriptions for identical content.
• Ignoring the reconnect storm. When a connection tier node dies, its clients reconnect at once. Without jitter and capped backoff, recovery is a self-inflicted denial of service.

What a strong answer adds

The failure plan: what the viewer sees when the push path is unhealthy, which is a poll-based fallback and a slightly staler score rather than a blank screen. And the honest note that the reported concurrency figure is public, while the delivery architecture behind it is not - so the design is reasoned from the constraints, not recited.