Design a video streaming service

01Choose on-demand upload and playback

Design a service for user-uploaded videos that viewers can play, pause, seek and resume on another device. Include titles, thumbnails, basic search, comments and reactions. The running example is a two-minute bicycle-repair video, v42. Its uploader wants reliable progress; its viewer wants playback that continues when Wi-Fi becomes a slower mobile connection.

Uploading the original is not the same as publishing a playable video. The service first accepts durable source bytes, then prepares a compatible output, then marks v42 READY. A failed encode must leave a useful processing or failure status instead of pretending that upload success means playback success.

Choose on-demand video for this interview. Live broadcasting, recommendation ranking and licensed subscription rights are separate extensions. For private videos, new playback sessions check current access. The worked delivery policy uses grants valid for up to five minutes; revocation stops new grants, while an already issued grant can remain usable until expiry. Agree to that limitation before designing a cache-heavy media path.

Clarify on-demand versus live video, the expected upload formats and sizes, acceptable startup delay, and how quickly private playback must stop after access changes. This design selects on-demand playback and an explicit five-minute existing-grant limit.

02Functional requirements

Agree on these supported actions before selecting components.

1. Upload and publish video. Authenticated creators upload resumable originals, inspect processing status and publish playable video only after its required rendition, thumbnail and manifest exist.

2. Play across supported devices. Viewers start, pause, seek and resume a video, selecting compatible prepared renditions as network conditions change.

3. Manage content and interaction. Provide titles, basic search, comments, reactions and owner deletion. These supporting features do not block segment delivery.

4. Authorize private playback. New private sessions require current access and receive an expiring delivery grant. The media edge validates that grant on manifest and segment requests.

03Non-functional requirements

Use these as illustrative interview assumptions to agree with the interviewer. Numerical targets require measurement; they are not claims about an existing product or a proven implementation. p95 (the 95th percentile) means 95% of measured operations finish within the stated time.

1. Workload. Use twenty million two-minute uploads/day and four billion playback starts/day. The worked average is approximately 2.78 million concurrent viewers and 13.9 Tb/s of delivered media; provision peak headroom from measured traffic rather than treating these averages as ceilings.

2. Playback experience. Target p95 time to first frame within two seconds for a ready video on a tested supported device/network profile, and aggregate rebuffered time below 1% of watched time on that profile. Report the profile and failures; neither target promises performance on every connection.

3. Processing delay. For the example two-minute, 20 MB clip within accepted codec/resolution limits, target p95 upload-complete-to-minimum-READY within 60 seconds at admitted load. Optional higher-quality outputs can follow later.

4. Durability and completeness. Accepted originals and published metadata must survive a worker restart or one storage-node failure within the region. A selected manifest must name complete immutable required outputs; a cache is not the durable archive.

5. Private-access lifetime. Stop issuing new grants after access is removed. An existing grant remains usable for at most its five-minute validity for new requests; already downloaded bytes and admitted transfers cannot be recalled.

6. Resource isolation. Bound upload and encode work independently of playback. Origin misses and retries must remain within storage capacity so a cache failure cannot create an unlimited request backlog.

04Make one uploaded video playable

Start with an application, a SQL metadata database, durable object storage and a background encoder. Object storage holds large files independently of database rows. The uploader creates upload up42, transfers the original and asks the API to complete it. The API verifies the expected length and checksum, then records PROCESSING and a durable encoding job in one database transaction.

The encoder reads that original and creates one broadly compatible rendition: a prepared version of the video at a particular quality and bitrate. It also creates a thumbnail and a manifest describing the playable output. Once required files are verified, the application updates v42 to READY with the selected manifest pointer. The viewer requests v42, receives the manifest and fetches its media from an origin server backed by object storage.

The job can initially be a database row polled by one worker; a separate queue service is unnecessary for a small library. If a worker dies, the source file and job remain available for retry. If the upload-completion response disappears, querying up42 returns its existing status.

This system already works. Its limitations are encoding throughput, one rendition’s suitability for changing networks and the origin’s delivery bandwidth. Those limits motivate more encoder workers, several prepared qualities and delivery caches.

05Count watched seconds and transferred bytes

Assume 800 million daily viewers watch five videos each: four billion starts/day, or about 46,296 starts/s. One upload per 200 views gives twenty million uploads/day, approximately 231/s. Each two-minute original averages 20 MB. Use decimal bytes; eight bits make one byte.

Delivery is governed by actual watched duration and selected bitrate, not merely the number of uploads. A 95% CDN byte-hit ratio would still leave approximately 87 GB/s of origin demand at this average. A hit ratio measures reuse at the cache; it does not remove the bytes sent to viewers.

Benchmark encoding on the chosen codec, resolution and hardware. If an illustrative clip requires twelve worker-seconds, 231 clips/s need about 2,772 continuously busy slots before reserve. Do not present that assumed benchmark as a universal encoder performance figure.

06Expose the lifecycle in the API

The client must distinguish incomplete upload from processing and ready-to-play status. A request key identifies one upload intent; changed content needs a new identity.

The upload API derives the owner from authentication and enforces size and duration limits. Direct upload authorization is restricted to the assigned object or part; it must not permit replacing another user’s files. Completion checks the final original, not only the existence of several uploaded parts.

Playback request

POST /videos/v42/playback

The phone can resume at the television’s saved media timestamp while selecting a different compatible rendition. It does not need the television’s exact encoded bytes.

07Separate source bytes, attempts and published outputs

The database records which stored files belong to each upload, processing attempt and published video. A file’s presence in storage alone does not make it public.

Partition metadata by video ID as traffic grows; add owner/time and title-search access paths for the uploader’s library and discovery. Store media bytes in private object storage. A popular v42 remains a hot key even with good partitioning, so repeated byte delivery needs cache copies rather than a different hash function.

Use immutable source and output identities. Enforce create-only writes or pin exact object versions; a filename convention alone does not prevent an accidental overwrite. Search and view counts may lag. Neither decides whether v42 is READY or whether a private playback session is permitted.

08Publish a complete output, not a work directory

An encoder writes its files under an attempt-specific path, such as v42/source1/attempt7. A segment is a short interval of encoded media; the manifest names the available renditions and their segment locations. Publishing a manifest before all required segments exist creates a deceptive failure: playback starts successfully, then encounters a missing file halfway through.

Define a minimum playable set, such as one compatible audio/video rendition and its thumbnail. Validate that set before publication. Optional higher-quality renditions can arrive later through a new immutable manifest version; they need not delay every initial viewer.

A replacement worker receives a new attempt number. The database accepts READY only if the submitted number is still current, the source matches and the video is not deleted. If old worker seven resumes after worker eight wins, its update is rejected. Their separate output paths also prevent seven from overwriting eight’s files. The database check protects the pointer; immutable storage protects the referenced bytes.

Cleanup must first mark an abandoned attempt ineligible to publish, using the same metadata state that publication checks. It can then delete unreferenced output files. Merely observing “old files” and deleting them risks removing an output that a slow worker is about to publish.

09Adapt future segments to the connection

Prepare several renditions at different bitrates, with segment boundaries at matching media times; this set is the bitrate ladder. Bitrate is encoded data per second of playback. The player downloads ahead into a buffer, which absorbs brief interruptions. If that buffer empties, playback stalls while more data arrives.

Compare two renditions over the same ideal 2 Mb/s connection:

The player measures recent throughput and buffer depth, then chooses a suitable rendition for subsequent segments. It does not ask the metadata API to transcode on every quality change. HTTP Live Streaming, or HLS, is one established manifest-and-segment format for this request pattern. The application still owns readiness and access policy.

Seeking to 75 seconds selects the appropriate segment and decoding boundary near that media time. Saved progress is advisory. Choose a latest-session policy: the server assigns a generation to a new resumable session and accepts increasing event sequences only from that generation. A late event from an older device cannot replace a newer deliberate seek merely because its offset is larger.

10Separate control requests from media delivery

Place a content delivery network, or CDN, between players and private media storage. An authorized edge serves cached immutable segments or fetches them from origin on a miss. The API handles upload management, metadata and playback authorization; it does not relay every media byte. This isolates upload sockets and encoder CPU from existing playback.

Use the selected five-minute grant at the delivery edge for manifest and segment access. A cache hit must still validate the grant. Its expiry is the explicit stale-access bound for new requests using that grant, rather than a claim that deleting a database row immediately removes every cached byte. Private grants should not appear in logs or public shared links.

An origin shield is a shared cache behind several edges. It can fetch a missing segment once for several waiting edges, reducing a viral clip’s load on storage. Add bounded origin retries and reserve playback capacity when uploads or encoding queues surge.

Scale encoder workers from measured queue age and processing cost, with per-account admission and bounded retries. More renditions improve network/device coverage but multiply compute and retained bytes. Cold videos may initially receive only the minimum playable set; optional encodes follow measured demand.

Use durable majority commits across three metadata replicas in independent regional failure domains, and media storage whose acknowledged writes survive one storage-node loss. Satisfy that policy before reporting original acceptance or publishing required outputs. The two-second startup and rebuffering targets still need playback tests, including origin misses; replication does not establish them.

11Explain what survives each failure

Deletion prevents new playback grants and schedules reclamation after the retained-grant/manifest window. It cannot recall already downloaded video. Back up original identities and publication metadata; caches are not the archive. Derivatives can be regenerated, but that takes time and compute, so restoring metadata alone does not instantly restore every rendition.

Comments, title search and approximate view counts have independent pagination and failure behavior. A slow counter must not block a segment. For a view metric, define what counts as a view before discussing deduplication; a request for the first segment is not proof that the person watched the clip.

12Check the design against the requirements

Use the agreed lists to check the finished design. The tests below still need to establish the targets; a proposed mechanism is not a measured result. FR refers to the numbered functional requirements above; NFR refers to the numbered non-functional requirements.

13Rapid revision

Remember: The player needs the next segment before its buffer empties. Lower bitrate buys playback time with fewer bytes.

Measure time to first frame, rebuffered time as a fraction of watched time, errors by device/codec and upload-to-READY delay. A successful manifest response alone proves none of these outcomes. Use synthetic players plus privacy-conscious playback telemetry to test real segments.

In the interview, finish by tracing v42 from verified original through accepted manifest to one adaptive playback session. Name the largest cost drivers: retained originals, useful rendition sets and watched bytes. Licensed catalogs would add entitlement and possibly digital rights management; live video would add moving manifests and a different latency budget. Those are deliberate extensions, not capabilities implied by this on-demand design.

Recall the key ideas

Answer from memory before opening each card. Explain why the choice works and what it costs. Revisit missed cards tomorrow.