How the interviewer opens it
“Design a service that lets remote participants watch the same video with shared playback controls. Keep ready, connected players aligned despite network delays. Players that stall must return to the shared playback position after recovery.”
The prompt is vague on purpose. The first minutes are for you. Reduce the prompt to the core features and agree on the numbers before you draw.
What to clarify first
- Room behavior and access
- Scale
- Traffic and read:write mix
- Clients and network
- Latency and alignment
- Video stalls
- Consistency and availability
- Durability
- Media delivery
- Guarantee limits and exclusions
The interviewer has the answers. In a SysRound round, Alex gives these answers, as a real interviewer does.
Scope of a strong answer
Core requirements
- Create a room and join the same video
- Share play, pause, and seek controls
- Keep ready, connected players within the alignment target
- Restore the correct position after a join, stall, or disconnect
Usually out of scope
- Video upload, video encoding, and CDN design
- Live video
- Chat and recommendations
- DRM implementation
- Active service across multiple regions
What interviewers ask about
- Shared playback behavior
- Participants can issue conflicting controls. A delayed message or duplicate request can reverse a newer action.
- Playback across different device clocks
- Clients have different clocks and receive controls at different times. Equal player positions at message receipt do not produce aligned playback.
- Video stalls
- A stalled player cannot meet a time target. The service must distinguish a local player failure from a shared control.
- Room state after a disconnect
- A participant can miss a control during a connection change. A stale snapshot can look valid after the participant returns.
Common mistakes
- Treats synchronization as a broadcast of play and pause events.
- Uses each client's wall clock as the shared time reference.
- Stores only a position without its reference time and playback mode.
- Lets local stalls change the room state without an explicit policy.
- Ignores the race between a room snapshot and live events.
- Designs video delivery instead of the shared control service.
The bar by level
- Senior (L5/E5)
- Handles control conflicts, duplicate requests, clock estimation, drift correction, and local stalls. Explains snapshot races and recovery after one server failure.
- Staff (L6+/E6+)
- Defines an error budget and the limits of the alignment target. Separates durable controls from high-volume status traffic. Justifies capacity, failure boundaries, and tests for delay, clock errors, and lost events.