Instant replay system design for a live cricket broadcast

The interview question is simple to say. Design an instant replay for a live cricket broadcast, where a wicket shows up from five angles, in slow motion, within seconds. The reel walks through it in under a minute. Here is the same design with a bit more room.

This is a standard interview design. It is not how Hotstar actually built its system.

Why the obvious answer fails

The common first answer is that someone grabs the clip from a camera and runs it over. Reject that. The match doesn't stop, and nobody is there to stitch five angles together by hand.

The design has three needs. The live feed never stops. The replay arrives within a few seconds. And all five angles show the same moment.

One clock, one buffer

Every camera sends its feed nonstop into a recorder. The recorder stamps every frame with a timecode from a single shared clock. That matters because separate clocks drift ahead and behind each other, and then the angles don't line up on the same instant.

The recording goes into a rolling buffer. It keeps only the last few minutes and overwrites the older part. Keeping the whole match would be expensive, and a replay only ever needs the recent past.

Mark times, don't copy clips

Here is the twist. The replay desk operator doesn't copy a clip. They mark a start and an end timestamp, an in and an out point.

Because every angle was stamped from the same clock, those two times are enough to find the matching slice in all five feeds. No copy step is needed.

The clip player takes that slice from each of the five feeds and plays them in slow motion. Then the director at the TV mixer cuts from the live feed to the replay.

The full chain runs in this order. Cameras send five angles on a nonstop feed to the recorder, which stamps timecode from one clock. The buffer holds the last few minutes on a loop. The replay desk is where the operator marks in and out. The clip player shows five angles in slow motion, and the TV mixer is where the director cuts to the replay.

What breaks first at peak

Ask the interviewer-style follow-up, what breaks first when load peaks? The answer is the buffer. If the operator is late, the older frames have already been overwritten. The status the reel shows is "buffer full, purana frame gaya", meaning the old frame is gone.

The fix in the reel is to keep a bigger buffer. That has a cost, since the buffer is the thing we said we didn't want to grow, but it is the direct answer to a late operator.

The reel ends on a question. Would you keep the buffer big, or make the operator faster? Both are defensible, and it's worth deciding which one you'd argue for before the interview.

Next time you practise a system design answer, say the four parts out loud: nonstop record, one clock, rolling buffer, timestamp mark. If you can explain why each one is there, you've got the answer.