Design a Clip & Share Feature for Live Streams

Problem statement

Design a feature that lets a viewer of a live broadcast capture the last 30 seconds of the stream, turn it into a standalone short clip, and share it through a unique link with minimal delay. The product surface looks trivial: one button in the player. The system behind it is not. A live stream has no finished file to copy. The only material that exists is a moving window of recently emitted segments, and the moment the viewer wants is already receding into the past at one second per second.

The design therefore starts from a hard physical fact: the last 30 seconds must already be stored somewhere addressable by wall-clock time, or the clip cannot exist. Everything else - validation, splicing, packaging, thumbnails, share links, moderation, analytics - is downstream of whether the platform maintains a rolling DVR buffer per live channel and can resolve a time range into concrete media segments quickly and correctly.

Why this is distinctive

A video-on-demand platform can re-read any byte at any time. A live clip feature operates against a decaying, ephemeral, per-channel buffer. If the buffer missed the window, no amount of compute can recover the clip. That asymmetry shapes every requirement: the buffer is write-heavy and disposable, the clip object is write-once and durable, the share link is read-heavy and globally cacheable, and the live ingest path must never be destabilized by a storm of clip requests on a viral moment.

The problem requires a rolling buffer for the last X seconds, finalizing a requested portion into a shareable link, optional trimming and titles, link-based access, concurrency across many simultaneous clip requests, low-latency availability, ephemeral segment storage, and a monetization hook. Those decompose into three architectural planes.

The three architectural planes

1. Live ingest and DVR plane: the existing live pipeline ingests, transcodes, and packages the stream into segments. Our feature attaches a rolling retention policy and a time-indexed segment lookup so any recent window can be addressed. This plane must keep serving live viewers no matter what clipping does.
2. Clip production plane: an asynchronous media pipeline that validates a request against the DVR index, fetches the covering segments, splices or repackages them into a standalone asset, generates a thumbnail, registers durable metadata, and publishes.
3. Social distribution plane: the clip as a shareable object - slug, page, Open Graph metadata, embeddable player, CDN delivery, view counters, moderation state, and takedown behavior.

A strong answer keeps these planes separate. Clip storms stress production and distribution; they must never back-pressure the ingest plane. And the distribution plane must tolerate the production plane being queued, degraded, or partially failed without showing broken pages to users.

Public operating baseline versus design assumptions

Public evidence establishes that this category is operationally central. Twitch launched Clips in December 2016, originally at 30 seconds and later extended up to 60 seconds, and reported 35 million average daily active users and 7.5 million monthly unique streamers in 2023. YouTube rolled out viewer Clips between 2020 and 2021, allowing segments of 5 to 60 seconds, and reported more than 2.5 billion monthly logged-in users in 2022. These are cited company figures, not requirements for our fictional system.

For capacity planning, this answer explicitly assumes a mature platform with 50 million DAU, 5 million concurrent live viewers at peak, 20,000 concurrent live channels, and 800,000 clip attempts per day with a five-times event peak. Unless a number is tied to a citation, it is a stated design assumption, target, budget, or illustrative threshold.