Design a 'Watch Together' Video Chat

Problem statement

Design a Watch Together experience where a group of friends watches the same licensed video at the same time. Any participant (or a host, depending on policy) can pause, resume, seek, and queue new content, and that control applies to every participant in near real time. While watching, the group discusses the content over text chat and an optional voice channel.

The trap most candidates fall into is treating this as one streaming problem. It is two problems with opposite scaling laws. The media plane moves hundreds of gigabits per second of encrypted video from a CDN to each client individually, exactly as solo viewing does. The session plane moves tiny control messages, chat messages, presence heartbeats, and voice packets among a small group, and it must do so with sub-second latency and strict per-party ordering. A candidate who tries to push the licensed video itself through WebRTC to the group has already failed: licensed content is protected by DRM, and redistributing it peer-to-peer violates both the license and the law. Each client must pull its own media stream from the CDN; the only thing we synchronize is time.

Why this problem is hard

First, clock synchronization across heterogeneous networks. Five phones on five different cellular conditions will drift apart even if they all start together. Buffering events, ABR quality switches, and decoder jitter each shift a client off the shared timeline. The system must continuously estimate each client's offset from the authoritative clock and correct it without the viewer noticing, using a ladder of corrections: do nothing, trim playback rate by one or two percent, or seek.

Second, control concurrency. Two users press pause and seek in the same hundred milliseconds. Who wins? The answer must be deterministic on every client without a round trip to a central brain for rendering, which means an authoritative state machine with monotonic versions and last-writer-wins resolution, replicated to clients as a snapshot stream.

Third, the slow participant must never hold the party hostage. In a naive design, everyone waits for the buffering friend. The correct design keeps the shared timeline moving; the slow client fast-forwards back into sync, exactly as a late arrival to a movie theater sits down while the film keeps playing.

Fourth, voice chat with guaranteed media sync. Voice is a WebRTC problem (SFU, jitter buffers, echo cancellation); video sync is a metadata problem. They must coexist in one room lifecycle: people join voice, leave voice, mute, reconnect, while the movie keeps its place.

Public operating baseline versus design assumptions

Public evidence shows this category is real. Discord reported more than 200 million monthly active users around 2021 and has described its voice and Go Live infrastructure as selective-forwarding, low-latency RTC. Amazon launched Prime Video Watch Party in 2020 supporting up to 100 participants with host-driven playback. Teleparty operates a browser-extension relay service that reports millions of users synchronizing playback across streaming services. Spotify ran a Group Session beta synchronizing music playback for up to ten listeners. These company-reported figures are context, not our requirements. For capacity planning this answer states explicit assumptions later: 50 million MAU, 5 million DAU, 200,000 concurrent watch parties at global peak, average four participants per party. Unless tied to a named company, every number here is a stated design assumption or target.

The four architectural planes

1. Media plane: CDN, per-title encodes, DRM, adaptive bitrate, per-client playback. Stateless with respect to the party.
2. Sync and control plane: the authoritative party timeline, versioned control commands, clock offset estimation, late-join snapshots. This is the heart of the interview.
3. Communication plane: text chat, presence, reactions, and the WebRTC voice room with an SFU fleet.
4. Fleet and governance plane: room directories, invitations, content search and queueing, moderation, analytics, and rollout.

A strong answer keeps these planes separate. The media plane may degrade to 480p without touching sync. The voice room may fail without pausing the movie. The sync plane is the only one whose correctness is user-visible every second.