Design a Rolling Buffer for DVR

Medium45 min
1 / 30
System design answer

Design a Rolling Buffer for DVR

Medium45 min30 sections
understanding•10 min read

Problem Statement: Live Time-Shifting at Broadcast Scale

Frames the rolling DVR buffer as a segment-level circular storage and indexing problem, not merely a caching exercise.

Problem statement

Design a rolling buffer for DVR that lets viewers of a live stream pause, rewind up to a configurable window (typically 2 hours), fast-forward back toward live, and then resume the live edge. The buffer continuously ingests newly encoded segments and evicts the oldest ones once the retention window is exceeded. Every concurrent viewer on every channel may be at a different point in the timeline, so the system must serve arbitrary seeks across a sliding window of stored media without re-encoding.

This is not a video-on-demand system. In VOD the full asset exists before any viewer arrives. In live DVR the asset is being written while it is being read, the readable window is finite and moving, and the oldest readable byte can vanish mid-seek. The design therefore separates three planes that most candidates conflate:

  1. Ingest plane — receives encoded segments from the live encoder or packager at a fixed cadence (one segment every 2–6 seconds per bitrate rendition).
  2. Buffer plane — the circular store that holds the retention window per channel per rendition, evicts expired segments, and answers range reads.
  3. Playback plane — the manifest, CDN, and player-facing APIs that translate a viewer's timeline position into the correct segment URLs.

Why the problem is distinctive

A CDN cache serves immutable objects. A DVR buffer serves a mutable window over an append-only stream. Segments are immutable once written, but the set of available segments changes every few seconds as new ones arrive and old ones expire. The manifest (HLS master/media playlist or DASH MPD) must reflect the current window accurately enough that a player never requests an evicted segment, yet loosely enough that CDN caching remains effective.

The problem requires segment-based ring buffer logic, an indexed timeline for quick jump, a return-to-live mechanism, multi-bitrate encoding in the buffer, scalability for many concurrent DVR watchers, high ingest throughput, stable seek logic, and cost optimization for storing hours of content across many channels.

Public operating baseline versus design assumptions

Public evidence establishes that the category is operationally real. YouTube supports DVR controls on live streams, allowing rewind to the start of the broadcast. Twitch serves approximately 35 million daily active users with average concurrent viewership around 2.5 million and peaks above 10 million during major events. Hulu Live TV offers cloud DVR with 9 hours of base storage. YouTube TV provides effectively unlimited cloud DVR with 9-month retention. Sky Q in the UK maintains a rolling buffer on live channels for instant rewind. Comcast X1 supports network DVR with multi-room streaming.

For capacity planning, this answer explicitly assumes a mature streaming platform with 500 live channels, 2 million concurrent viewers at peak, a 2-hour DVR window, and a 5× event peak multiplier. Unless a number is tied to a published figure, it is a stated design assumption.

The three architectural planes

  1. Ingest plane: encoder output, packaging into HLS/DASH segments, manifest generation.
  2. Buffer plane: circular segment store per channel, timeline index, eviction policy, multi-rendition management.
  3. Playback plane: CDN distribution, player manifest delivery, seek API, catch-up logic, ABR switching within the buffer.

A strong interview answer keeps these planes separate. It allows the playback plane to degrade (serve slightly stale manifests) without corrupting the buffer plane, and it permits the ingest plane to continue writing even when playback load spikes.

Key Highlights

  • •The buffer is a sliding window over an append-only segment stream, not a static cache.
  • •Segments are immutable once written; the window boundary is what moves.
  • •Three planes: ingest, buffer, playback — each with different consistency and latency needs.
  • •Public DVR implementations at YouTube, Twitch, Sky, and Comcast prove the pattern at scale.
  • •Every uncited scale number in this answer is an explicit design assumption, not a company claim.
Lead With the Write-While-Read Distinction
State in the first minute that DVR is not VOD: the readable window moves while viewers are reading from it. This instantly separates a streaming architecture from a generic storage answer.
Do Not Treat the Buffer as a Simple Cache
A CDN cache serves immutable objects with no expiry race. A DVR buffer has a moving expiry boundary that can invalidate a segment between the manifest fetch and the segment request. Designing around that race is the core challenge.

Section Rescue Kit

Buzzwords to use:

Sliding Window StoreWrite-While-Read

Safe statements:

  • "I will separate ingest, buffer storage, and playback because they have different consistency and latency requirements."
  • "Before selecting storage, let me define what moves and what stays fixed: segments are immutable, the window boundary moves."
Design a Rolling Buffer for DVR - System Design | WinJob | WinJob