System Design: [Video platform name]

Reference design for video upload and adaptive bitrate streaming: resumable upload, a transcoding pipeline that produces a renditions ladder, CMAF packaging for HLS and DASH, CDN delivery, a DRM note, view counting, storage tiers and cost. It follows the structure of the System Design Document template and is pre-filled with a worked design to adapt. Values marked Example are assumptions: replace them and recompute; egress and storage numbers move by orders of magnitude with your audience.

Document control

Approvals

Revision history

Contents

1. Overview
2. Requirements
3. Capacity estimation
4. API design
5. Data model
6. High-level design
7. Detailed design
8. Scalability and performance
9. Reliability, security and operations
10. Trade-offs and alternatives
11. Delivery plan and risks
12. Appendices

1. Overview

1.1 Problem statement

[Example: Creators upload MP4 files that we serve as progressive downloads from a single bucket. Mobile viewers on weak networks stall every 20 seconds, a 4 GB upload fails if the connection drops, and our cloud egress bill grew 4x in a year.]

1.2 Proposed solution

[Example: Clients upload directly to object storage with resumable, chunked uploads. An upload event starts a transcoding workflow that splits the source into chunks, encodes them in parallel into a ladder of renditions, and packages fragmented MP4 segments (CMAF) with HLS and DASH manifests. Players choose the rendition per segment based on measured throughput (adaptive bitrate). A CDN serves segments from the edge with an origin shield in front of storage. View events stream into an aggregation pipeline for counts and analytics. Older and rarely watched renditions move to cheaper storage tiers.]

1.3 Decisions requested from reviewers

2. Requirements

2.1 Functional requirements

2.2 Non-functional requirements

2.3 Out of scope

• [Example: live streaming (separate design: ingest, low-latency packaging)]
• [Example: recommendations and search]
• [Example: in-browser video editing]
• [Item deferred, with the release that will take it]

3. Capacity estimation

3.1 Assumptions

3.2 Storage

Source per video: $600 \ \text{s} \times 8 \ \text{Mbit/s} = 4\,800 \ \text{Mbit} = 600 \ \text{MB}$. Renditions per video: $600 \times 10.7 = 6\,420 \ \text{Mbit} \approx 800 \ \text{MB}$.

Storage tiering (7.7) is therefore part of the design, not an afterthought.

3.3 Transcoding compute

Spot or preemptible capacity suits this load because chunks are short and retryable.

3.4 Egress

3.5 Summary

4. API design

4.1 Endpoints

4.2 Request and response examples

The playback endpoint returns short-lived signed URLs for both manifest types:

GET /v1/videos/v_9QK2/playback HTTP/1.1
Authorization: Bearer [viewer token]

{"videoId": "v_9QK2", "hls": "https://cdn.example.net/v/v_9QK2/master.m3u8?token=eyJ...", "dash": "https://cdn.example.net/v/v_9QK2/manifest.mpd?token=eyJ...", "expiresAt": "2026-03-14T20:00:00Z", "drm": null, "captions": [{"lang": "en", "url": "https://cdn.example.net/v/v_9QK2/en.vtt"}]}

4.3 Errors and limits

5. Data model

5.1 Entities

Video metadata lives in a database; media objects live in object storage and are referenced by key.

5.2 Storage choices

6. High-level design

Uploads and playback never pass through application servers; the API only issues signed URLs and tracks state.

7. Detailed design

7.1 Upload and processing workflow

Processing state is a small state machine stored on the video record; the workflow engine drives transitions and retries each step independently.

A video becomes ready as soon as the 360p and 720p renditions exist, so viewers can start watching while higher renditions finish.

7.2 Renditions ladder

The video bitrates sum to 10.7 Mbit/s (the $b_l$ input in 3.1; audio is shared across renditions and adds little). Per-title encoding can lower these bitrates substantially for simple content such as slides or animation; adopt it once quality metrics (for example VMAF) are in place. AV1 renditions save roughly 30% or more bandwidth at equal quality on supporting devices but cost several times more compute, so they are produced only for videos above Example: 1 000 views, where egress savings exceed encoding cost.

7.3 Chunked encoding and packaging

• The source is probed, then split at keyframes into chunks of about 30 s.
• Each chunk is encoded per rendition with a fixed GOP of 2 s and closed GOPs so segments align across renditions; players can switch at any segment boundary.
• The packager writes CMAF fragmented MP4 segments of 4 s, one HLS master playlist with media playlists, and one DASH MPD, all referencing the same segment files.
• Failed chunks are retried individually (up to 3 attempts, then on on-demand capacity), so a spot interruption costs at most one chunk.

7.4 Playback path (critical path)

The player fetches a manifest, then segments, choosing a rendition per segment from throughput and buffer level.

Manifests for on-demand videos are immutable after ready, except when renditions are added; they are cached for minutes, segments for a year.

7.5 DRM note

For licensed content, segments are encrypted with Common Encryption (CENC) using the cbcs scheme, which lets one set of CMAF segments work with FairPlay (Apple devices), Widevine (Chrome, Android) and PlayReady (Windows, many TVs). The licence service checks entitlement and issues keys with policies (rental expiry, output protection). DRM requires licensing agreements with each DRM vendor, adds a licence round trip to startup and complicates offline playback; user uploads without licensing obligations use signed URLs and token-authenticated CDN access instead.

7.6 View counting and consistency model

• Players send a view-start event with a random viewId, then heartbeats. A view counts once watch time passes Example: 30 s, which filters autoplay noise.
• The stream job deduplicates by viewId, drops bot traffic by rules and reputation, and updates per-minute aggregates; public counts are refreshed every 5 minutes. Counts are eventually consistent and can be corrected downward after fraud review.
• Video metadata and state changes are strongly consistent in the database. Segments are immutable objects, so CDN caches can never serve a mixed version of a segment; deletions propagate by CDN purge within minutes.

7.7 Storage tiers

8. Scalability and performance

Startup budget for a video start (target p90 1.5 s):

9. Reliability, security and operations

9.1 Failure modes

9.2 Security and abuse

9.3 Observability

9.4 Cost estimate

10. Trade-offs and alternatives

11. Delivery plan and risks

11.1 Milestones

11.2 Rollout and rollback

[Example: Re-encode the existing catalogue in the background, most viewed first. The player chooses adaptive streaming when a ready ladder exists and falls back to the old MP4 otherwise; rollback sets a flag that forces the MP4 path.]

11.3 Risks

12. Appendices

12.1 Open questions

12.2 Glossary

12.3 References

Standard and licence note

Based on common industry practice for video-on-demand platforms and on the specifications cited in 12.3; no text from ISO/IEC standards is reproduced. This is a reference design to adapt, with illustrative numbers and prices. Original text written for this collection. Template licence: MIT.