Katkat
Back

Design a Synchronized Watch Party System (LLD)

SalesforceSoftware Engineer · Onsite
MediumSoftware EngineerOnsiteSystem Design

Last updated

Design a low-level object-oriented system for real-time synchronized video playback among multiple participants. The challenge tests class design, state synchronization protocols, and handling of network latency and clock drift.

Scenario

You are tasked with designing the low-level architecture for a Synchronized Watch Party engine (such as for a collaborative streaming feature). The system allows a group of users to watch a video together in real time, ensuring that actions like play, pause, seek, and playback rate adjustments stay synchronized across all participants despite differences in network latency and clock drift.

Requirements

Functional Requirements

  • Session Management: Users can create a party, join via a session ID, and leave. A session has an assigned host (creator) and one or more participants.
  • Playback Actions: Support core playback commands: PLAY, PAUSE, SEEK(target_time), and SET_RATE(speed).
  • Permission Modes: Support both Host-Only control (only the host can issue playback commands) and Collaborative control (any participant can issue commands).
  • State Synchronization: When a participant joins late or re-syncs, they must receive the current authoritative playback state.
  • Drift Correction: The system must actively detect and correct playback drift (e.g., client is > 200ms ahead or behind the expected session position).

Non-Functional Requirements

  • Target Drift: Keep all active clients within 100–250ms of each other under standard broadband connections.
  • Extensibility: Support pluggable transport layers (e.g., WebSockets, Server-Sent Events, or WebRTC DataChannels).
  • Thread-Safety & Concurrency: The in-memory session state must handle concurrent events safely.

Deliverables

  1. Class Diagram & Object Model: Define the primary classes/interfaces, their responsibilities, and relationships (e.g., WatchPartySession, Participant, PlaybackState, SyncStrategy, ConnectionAdapter).
  2. State & Event Design: Define the schema for synchronization events (e.g., payloads for PLAY, SEEK, SYNC_HEARTBEAT).
  3. Latency & Drift Handling: Detail the algorithm used by clients and the server to account for round-trip time (RTT) and determine when to apply soft correction (adjusting playback rate slightly) vs. hard correction (seeking to target time).
  4. Failure Handling: How the system handles a disconnected host, dropped packets, and temporary client freezes.

Hints

Hint 1

Separate playback state logic from network transport so the synchronization engine can be tested independently of WebSockets or HTTP.

Hint 2

Use a server-authoritative timestamp paired with round-trip time (RTT) estimation (similar to simple NTP) to compute the true current video position on each client.

Hint 3

Differentiate between minor drift (correctable by temporarily adjusting the video playback rate by ±5%) and major drift (requiring a hard seek).

Follow-up questions

  • How would you prevent a high-latency participant who sends delayed commands from inadvertently rewinding the video for everyone else?
  • If the host suddenly disconnects in a Host-Only control room, how should host migration and command buffering be handled?
  • How would you adapt this design to operate over a peer-to-peer mesh using WebRTC DataChannels without a centralized relay server?