System Design

Watch History

Design the watch history and continue watching feature for a service like Netflix.

Functional requirements

While a user watches a title, the client reports the current playback position every few seconds so the service always knows roughly where they are.
When a user opens a title on any device, playback resumes from the position they last reached, even if they stopped on a different device moments earlier.
The home screen shows a Continue Watching row: the user's most recently watched, unfinished titles in recency order, each with a progress percentage.
A title watched to the end is marked completed and leaves the row; for episodic content, the row entry advances to the next unwatched episode.
Users can view their full watch history and remove individual titles from it, which also removes them from the row.

The Continue Watching row is on the home screen's critical path: p99 under 50ms for the row and under 100ms for the resume-position lookup at play start.
Availability over consistency for positions: a report may lag by seconds and two devices may briefly disagree, but a completed title must never regress to partially watched, and no user may ever see another user's history.
A pause or stop must make the position durable within seconds, surviving any single node failure; mid-playback reports may sit in memory as long as a crash costs a viewer at most one minute of progress.
Position reports are fire-and-forget: a slow or overloaded service must never stall, buffer, or interrupt playback.
History is private to the owning account, and a title the user removes must disappear from every surface within seconds.

150M subscribers, 20M concurrent streams at prime time; clients report position every 5 seconds, so ~4M reports/s at peak and ~1M/s on average.
Reads are the minority: ~50K row loads and resume lookups per second at peak against ~4M position writes, a write:read ratio near 80:1.
A position report is ~100 bytes; stored state per (user, title) is ~200 bytes; an average user has ~30 in-progress titles and ~500 history entries, retained for the life of the account.
The catalog is ~20,000 titles and ~500,000 episodes; a hit release can put 5M users on the same title in the same hour.
Load ramps 4x between 5pm and 8pm in each time zone, and a mass reconnect after a player or CDN outage can make 10M clients resume within 60 seconds.
About 15% of accounts use two devices in the same hour and ~1% of sessions have two devices playing the same title at once; client clocks can be minutes off.

Get a score, what your board does well, what to fix first, and what an interviewer would ask next.