Design a video streaming service

01Problem and scope

A video streaming service ingests media, prepares playable representations, and delivers them efficiently as viewer bandwidth changes. A codec defines how media is encoded and decoded; a rendition is one prepared quality and bitrate; a segment is a short playable piece; a manifest lists renditions and segment locations. For example, a two-minute video can offer aligned segments at several bitrates so a player moving from Wi-Fi to a slower mobile link can request a lower-quality next segment without downloading the original again.

Bitrate is the amount of encoded media data needed per second of playback. The player downloads ahead into a buffer so brief network slowdowns need not interrupt viewing. If that buffer empties, playback pauses to refill it; this is rebuffering. Preparing several bitrates lets the player trade picture quality for a download rate its connection can sustain.

This design covers user uploads and on-demand playback with search and basic interactions; live streaming and recommendation ranking are outside the core. A completed original upload returns durable processing status, while READY requires a verified playable output set. A licensed subscription catalog adds licensing windows, regional entitlement and often digital rights management (DRM), including a service that releases decryption keys to authorized players. Those are additional authorization requirements, not synonyms for the upload product.

Support resumable uploads, status, title search, thumbnails, comments, likes/dislikes, view statistics, sharing, seeking and cross-device resume. Exclude subscriptions, recommendation ranking, watch-later collections and live low-latency broadcasting. Include encoding, storage, thumbnails, deduplication and delivery. Derive each capacity estimate from the same upload and viewing assumptions so the totals describe one coherent workload.

02Functional requirements

1. Resume upload: Retry missing parts without resending verified completed parts.
2. Complete original: Durable original plus recoverable processing job.
3. Publish: Every required object in the selected manifest exists and matches its version.
4. Play/seek: Compatible rendition and segment near the requested media timestamp.
5. Resume on another device: Stored progress is advisory; new device selects its own codec/quality.
6. Search/comment/rate: Visible video identity; interactions have independent pagination and retry behavior.
7. Delete: Stop new authorized playback, then reclaim retained outputs safely.

Upload lifecycle and status delivery

An upload has states UPLOADING, PROCESSING, READY, FAILED and DELETED. UPLOADING means incomplete bytes; PROCESSING means the original is durable but variants are not published; READY means the required manifest, segments and thumbnail are verified. The UI shows each distinction. A notification may announce READY through the app or an optional email integration; status polling remains available if that notification is missed.

Publication scope and retained media

We require a minimum playable rendition set rather than waiting forever for every optional high-resolution encode. Upgrading later publishes a new immutable manifest version. View counts are approximate and asynchronously deduplicated under a defined counting policy. A byte-identical upload may be reusable, but similarity is not proof of ownership or permission. Already downloaded media cannot be recalled by deleting its database row.

03Non-functional requirements

Playback authorization decides whether the viewer may receive a video. A short-lived delivery grant carries that permission to the media-serving layer. A content delivery network (CDN) caches the permitted media near viewers, while the origin is the backing service or store used when a cache misses. These separate roles explain why authorization latency, startup delay and stored-original durability have different targets.

1. Playback authorization: p95 below 150 ms.
2. Startup latency: Start-to-first-frame p95 below two seconds on a stated adequate test network.
3. Availability: 99.9% eligible playback-start availability.
4. Rebuffering: Below 1% of watched time in the measured network cohort; report this separately from startup latency.
5. Upload processing: 95% of ordinary two-minute videos become READY within five minutes at planned load. Extremely complex or invalid media may fail with a reason instead of remaining indefinitely in processing.
6. Durability: Acknowledged originals and publication metadata survive one storage-node or availability-zone failure. Regenerating derivatives costs time and compute.
7. Regional recovery: Initially replicate originals/metadata asynchronously with a tested recovery point and restore time. A CDN does not imply absolute zero loss.
8. Private-media revocation: New playback authorization checks current ownership/entitlement. Delivery grants last up to five minutes in this exercise, making the stale-access interval explicit.

Publication and outage boundaries

Immediate revocation is a different contract

04Capacity estimates

Workload assumptions and arithmetic

Assume 800 million daily viewers watching five videos/day: four billion starts/day, or 46,296 starts/s. One upload per 200 views gives twenty million uploads/day, or 231/s. Use a two-minute original at 10 MB/minute: 20 MB/upload produces 400 TB/day of original ingress, about 4.63 GB/s. All derived renditions together at 50 MB/minute produce another 2 PB/day. These figures imply about 463 uploaded hours/minute. Rounding that to 500 uploaded hours/minute is reasonable for an initial estimate, but downstream calculations must identify which figure they use.

Assume a view watches sixty seconds at a mean 5 Mb/s. Concurrent playback is 46,296 starts/s × 60 s ≈ 2.78M viewers. Egress is 2.78M × 5 Mb/s ≈ 13.9 Tb/s, or 1.74 TB/s. This depends on watch duration and selected bitrate, not just the upload:view ratio. A threefold traffic peak would triple concurrency and delivery demand unless user behavior changes.

Worked estimates

Capacity implications and limits

Encoding capacity must be benchmarked for the chosen codec, resolution ladder and hardware. A measured twelve worker-seconds per assumed clip would require 231 × 12 ≈ 2,772 busy worker slots on average, before peak and failure reserve. This is an illustrative measurement input, not a portable encoder performance claim.

05APIs and contracts

Request and response example

The uploader calls POST /v1/video-uploads with request key upload-v42 and {"title":"Bicycle brake adjustment","bytes":20000000,"language":"en","visibility":"public"}. The service returns videoId:v42, uploadId:up42, permitted part targets and expiry. Optional description, tags, category and recording location are metadata fields; collect location only when the product needs it. Completion verifies the original and returns 202 PROCESSING plus a queryable status URL.

Interface contracts

Validation and response semantics

Resume position is a media timestamp, not a requirement to reuse the TV's exact codec on a phone. The phone advertises its capabilities and chooses a compatible rendition. A repeated upload key with different metadata/content identity returns 409; malformed formats, oversized bytes and exhausted quotas have explicit errors. A timed-out completion checks the same upload session rather than uploading a second v42. Search continuation tokens are opaque and scoped to the query/version policy.

06Data model and access patterns

Track byte transfer, encoding and publication separately because success in one stage does not complete the others. Upload records the original's transfer; EncodeJob tracks attempts to prepare playable media; Manifest identifies the accepted output set; Video names the version viewers may use. The outbox durably records the next stage's work alongside the metadata change that requires it.

Users, reactions, comments and progress are separate records. Comments index (videoId,createdAt,commentId) for bounded pages; reactions have a unique user/video identity. Counts are derived, so one popular video's views do not serialize every playback on a metadata row. Progress updates use a session generation and monotonically increasing event sequence; a late old event must not overwrite a newer seek/pause choice merely because its numeric playback offset is larger.

Partition primary metadata by video ID with an owner/time index for the uploader's library and a title-search index for discovery. User-based placement offers gallery locality but can create hot publishers; video-based hashing still leaves viral v42 hot. Replicated caches and CDN copies address that repeated key. Original and derived objects live in private durable storage; metadata decides whether they are published and authorized. Thumbnail objects may use object storage with caching or a packed small-object store; choose from measured operation cost and latency, not an assumption that every image requires a separate disk seek.

Define cross-device progress ordering explicitly. In this version the service allocates an increasing playback-session generation for each user/video when a new resumable session starts; progress accepts only that generation and an increasing event sequence within it. The latest session controls the shared resume point, while older simultaneous sessions may continue playing but cannot overwrite it. This is a product policy, not a claim that wall clocks order devices; separate per-device progress is an alternative.

07Basic working design

Durable original and background encoder

Begin with one application, a SQL metadata database, durable original storage and one background encoder. The uploader uploads a complete file, the API verifies it and transactionally stores PROCESSING plus an encoding intention. The worker creates one broadly compatible rendition and thumbnail under an isolated output prefix. After checking them, it publishes READY metadata with the immutable manifest pointer. The viewer obtains that manifest and fetches media from the local origin server.

One database can schedule work

Even at small scale the encoder should not occupy an HTTP request for minutes. An outbox or job table inside the metadata database is enough for durable scheduling; a separate queue product is not mandatory. If the app crashes after committing the job but before responding, upload-v42 returns the existing v42 state. A worker crash can retry its attempt without making partial outputs visible.

Baseline playback and bottlenecks

This baseline can serve a small training-video library and supports pause, seek and resume with ordinary prepared files/segments. Its limitations are one encoding queue, one origin's egress, a single quality choice and limited failure isolation. Backups retain originals plus publication state; derived bytes can be rebuilt but rebuilding is a recovery delay. These are the limits that motivate separate encoding capacity, more playback qualities and delivery caches.

08Find the baseline flaws

09Improve the design, step by step

1. Use resumable direct uploads with isolated control capacity. Large-file network interruption triggers part-based upload sessions. Clients retry missing parts to private storage; the API verifies completion and commits the processing job. This saves retransmission and protects playback APIs from slow upload sockets. Costs are session metadata, abandoned parts and scoped-token expiry. Single PUT remains simpler for small clips; multipart is selected by size/reliability needs, not because every object requires it.

2. Scale a leased encoding pipeline and publish manifests atomically. When jobs wait too long or require several formats, add workers. Each attempt writes separate immutable outputs; the database checks its attempt token before publishing READY. This increases processing throughput and makes retries recoverable. Costs are encoder compute, rendition storage and duplicate abandoned attempts. Waiting for every optional rendition is rejected; publish a defined minimum set and add a new manifest later if optional outputs complete.

3. Add adaptive segmented playback. The viewer's bandwidth change triggers aligned rendition segment timelines and device-compatible manifests. The player can switch future requests without restarting the whole video, improving rebuffer behavior. Costs include more output bytes, encoding and player logic. A single progressive file is simpler for short controlled-network content, and live streaming requires a different moving-manifest/latency design.

4. Place delivery caches near viewers and partition metadata services. Origin egress and global latency trigger CDN caches, origin shielding and replicated metadata/read caches. Hot segments are reused across viewers while uploads/encoders remain isolated. Costs include cache misses, authorization distribution, purge complexity and delivery charges measured in bytes. Keeping rarely watched content at origin can be sensible; blindly pushing every rendition everywhere wastes storage and transfer.

An origin shield is a shared cache between many delivery-edge caches and the origin. If several edges miss the same popular segment, the shield can reuse a single cached copy and coalesce concurrent fills instead of sending every miss to origin storage. It protects the origin from repeated work but adds another cache and request hop.

Search, comments and counters become independent derived/read services only when their load warrants it. They cannot be allowed to delay already authorized segment delivery or redefine whether an encoding generation is ready.

10Detailed architecture

Control APIs and publication authority

The control edge routes upload management, metadata, search and playback authorization to stateless APIs. The storage leader for each video’s metadata partition commits upload states, job/outbox rows, manifest pointers and visibility through its replica group. This leader is the metadata owner referred to in the publication protocol. A title index, comments and reaction/progress stores support product queries with their own keys. A read replica with lag may serve discovery but cannot mint new private playback grants if it cannot establish the required current permission state.

Encoding and manifest publication

The processing path consumes durable encoding jobs, reads the original and writes attempt-specific variants and thumbnails. A publisher checks the required objects, then asks the metadata database to publish the manifest only if its attempt is still current. The original store has separate durability and retention from caches; losing a worker does not lose the source video. The final diagram combines encoder and thumbnail work in one worker tier because they share the source and job lifecycle, while allowing separate queues if measured resource needs differ.

Adaptive media delivery

The media path runs from the viewer's player to an authorized delivery edge, then regional/origin caches and immutable object storage on a miss. The API does not proxy every segment. Tokens/cookies may authorize a family of segment URLs for one session, which avoids a central database round trip for each of roughly 694,000 average segment requests/s. That choice explicitly bounds revocation by grant lifetime. Telemetry is asynchronous and never blocks a segment because a view counter is slow.

Partition ownership and hot keys

When a partition moves or a leader fails, routing directs requests to the new owner and storage rejects writes from the old owner. Consistent hashing can reduce cache-key movement, but it neither creates durable replicas nor cures a viral segment's skew by itself.

Concrete implementation choices

HTTP Live Streaming (HLS) is one format family for describing available renditions and serving their segments over HTTP. It supplies the player's media request structure; the surrounding application must still decide when those outputs are complete and who may fetch them.

A concrete implementation can begin with PostgreSQL metadata/job transactions, a managed durable object store, a file-based encoder such as MediaConvert or sandboxed encoder workers, and HLS manifests behind a CDN. The encoder product prepares media; the application still owns request deduplication, required-output validation, publication fencing, authorization and cleanup. Add a separate queue when independent worker throughput or operational isolation justifies it; a database job table remains a valid small baseline.

11Write path and acknowledgement

Media publication commits an immutable verified output generation rather than exposing a directory still being encoded. The trace uses video v42, upload up42 and source generation g1.

1. The uploader authenticates and reserves up42/v42 with expected length, checksum and source generation g1. The API returns constrained part-upload authorization.
2. The upload client uploads parts, records completed part identities locally and retries missing parts after a network break. The trusted completion path finalizes the approved part list and verifies the resulting object, not merely the existence of a few uploaded parts. It pins the returned immutable object version and checksum to g1; encoders read that exact version. Reusable upload authorization must not let a later write silently change the source being encoded.
3. The completion API checks ownership and session validity, then commits PROCESSING and outbox job encode-v42-1. The uploader receives 202 and can poll status. If the response is lost, retry returns this same job identity.
4. Worker W1 claims attempt token 41, reads the durable original and generates required renditions/thumbnail under v42/g1/attempt41/.... Resource limits bound decoding time, memory and output size.
5. A validator checks segment presence, declared durations, codec compatibility and the complete required manifest. Optional outputs may remain absent under the minimum-set policy.
6. The metadata owner atomically requires the current token and source generation, no deletion, and PROCESSING state before setting READY with manifest version 1 and a publication outbox event.
7. Search indexing and user notification consume the committed publication event. If the worker crashes after step 6, repeating publication returns the accepted manifest instead of creating a second version. Abandoned attempts remain invisible and are reclaimed only after their publication rights expire or are superseded.

Changing the uploader's original requires a new source generation. No retry may write different bytes under the accepted immutable object identity.

12Read and delivery path

Playback separates authorization from repeated media transfer. This trace uses manifest version 1 for video v42, then shows segment selection, adaptation, seeking and ordered progress updates.

1. The viewer requests playback for v42 with device codec capabilities and optional resume offset. The API verifies current visibility/entitlement and READY state, then returns manifest version 1 and a five-minute scoped media grant.
2. The player requests the manifest through the delivery edge. The edge validates the grant before serving cached bytes or fetching the private origin. Manifest version 1 always names the same accepted segment set.
3. The viewer's player chooses a compatible starting rendition, fetches enough initial media to begin playback and measures transfer speed plus buffer depth. Startup is reported separately from steady-state throughput.
4. It fetches successive four-second segments. When bandwidth drops, it requests subsequent aligned segments from a lower-bitrate rendition. Previously buffered segments remain useful; the metadata database is not involved in each switch.
5. Seeking to 75 seconds selects the appropriate media-time segment/keyframe boundary according to the format, then decodes to the requested position. Byte offsets and media timestamps are not interchangeable.
6. The player periodically saves progress with a playback-session sequence. The viewer's phone later loads that advisory offset but chooses its own rendition/codec. Out-of-order old progress events cannot replace a newer deliberate seek.
7. Quality-of-experience (QoE) events report startup delay, playback stalls and selected bitrate asynchronously. A stats outage should not pause the film. A token nearing expiry refreshes through authorization; if permission has been revoked, new grants stop even if segment bytes remain cached.

Repeated cache redirections add requests and startup latency. Prefer deliberate edge routing and bounded origin fallback rather than bouncing a viewer through an unbounded chain of increasingly distant caches.

13Correctness deep dive

Lease and token responsibilities

A job lease permits a worker to attempt processing for a bounded time; an increasing attempt token identifies the currently authorized publisher. The metadata owner enforces that token atomically at publication. The object store cannot be assumed to understand the metadata lease, so output names must isolate attempts.

A stale encoder resumes

W1 writes ten 720p segments, pauses and loses its lease. W2 claims 42, encodes a complete required set and publishes manifest B. W1 wakes and writes more attempt41 segments. Those cannot replace B's objects because B names attempt42 paths. W1's metadata update fails the token check. Thus both the pointer and its bytes are protected. A “fencing token” that is checked only by a worker's own code would not prove this outcome; the authoritative metadata write must enforce it.

Deletion and retained sessions

Deletion is serialized at the same video owner. If DELETED commits first, neither worker may publish; if READY commits first, deletion removes new authorization and schedules cleanup. Reclamation must account for active playback-token lifetime and retained manifest versions before deleting their segments. A garbage collector first proves an attempt is no longer publishable; an elapsed wall-clock guess alone is insufficient if a worker can renew or publish afterward.

Define the minimum playable set

The minimum playable set must be concrete, such as one compatible audio/video rendition and thumbnail. “Most files exist” is not a publication criterion. Validation failures remain PROCESSING/FAILED and do not leak a half-complete playlist to viewers.

Prevent rewrites of published objects

Collection must revoke publication rights

14Failure and recovery

15Operations, security, and cost

Upload and playback quality signals

Operational metrics include completed uploads, abandoned multipart bytes, oldest encoding job, attempts per video, whether every READY manifest names existing, verified segments, first-frame delay, rebuffer ratio, playback errors by device/codec and CDN origin egress. A 200 response for a manifest is not proof of successful playback. Sample synthetic players should fetch and decode real segments from representative regions and devices, while privacy-conscious client telemetry measures real user outcomes.

Codec, rendition and delivery economics

Codec/ladder choices trade storage and compute against delivery bytes. Saving 1 Mb/s for the assumed 2.78 million concurrent viewers reduces network throughput by about 2.78 Tb/s, or 347 GB/s, if perceptual quality remains acceptable. That potential must be balanced against additional encoder-seconds, device compatibility and retained rendition bytes, not guessed cloud prices. Long-tail videos with one or two views may not justify every expensive rendition in advance; an explicitly delayed optional encode can be more economical.

Sandboxing and private grants

Sandbox parsers/decoders, impose CPU, memory, duration and dimension limits, validate actual format rather than filename, and restrict workers' object permissions. Protect private media grants and avoid logging them. Title search, comments and reactions need abuse/rate controls distinct from byte-upload quotas. Retain only necessary location and viewer analytics.

Encoder rollout and failure drills

Test interrupted uploads, expired tokens, W1/W2 publication races, missing required segments, delete during playback, origin failure and codec rollout rollback. Test a new encoder/manifest version by encoding alongside the current version, comparing integrity and quality, then serving a small trial audience before switching publication. Keep prior accepted outputs through a rollback/token-expiry window rather than deleting them when a new job merely starts.

16Decision ledger and limitations

Exact byte deduplication can use hashes as candidate identifiers with collision/integrity handling and retained references. Inline checks may save upload/encoding/storage earlier but add latency and privacy risks. Background deduplication simplifies ingestion while temporarily consuming duplicate resources. Perceptual matching can flag differently encoded clips, borders, overlays or excerpts; block matching and phase correlation are examples of similarity techniques, not proof that outputs are interchangeable or the uploader owns rights. Reusing media must preserve permissions and quality requirements.

The similarity techniques above compare visual structure rather than exact file bytes. Block matching searches for corresponding image patches; phase correlation estimates how far matching image content has shifted between frames. Their role is to find possible matches for further policy checks, not to establish a right to reuse another upload.

For thumbnails, object storage plus CDN may be sufficient; packed small-object storage can reduce per-object operation overhead at scale but adds retrieval/lifecycle complexity. Metadata caches using least-recently-used (LRU) eviction need estimates of distinct hot objects and actual memory overhead, not a percentage of repeated daily views. Cold original retention, higher-resolution variants and global replication are policy choices with visible cost. No cache distribution algorithm alone supplies fault tolerance or balances every viral key.

17Interview closing

“I designed resumable user uploads and on-demand playback, with title search, thumbnails and basic interactions. The uploader's original becomes durable before a recoverable encoding job runs. READY is a guarded pointer to a complete immutable manifest; an obsolete worker cannot publish or overwrite the accepted attempt's objects. The viewer obtains authorization once for a bounded media session, then the player fetches compatible segments through delivery caches and adjusts future quality as bandwidth changes.

“The assumptions produce about 46,000 starts per second and 2.78 million concurrent viewers, so delivery bytes dominate the API path. Segment traffic is much higher than startup QPS. I separate upload, processing, metadata and media-serving resources, accepting encoding/storage cost for smooth compatible playback. Short-lived grants make the revocation limitation explicit.

“My next measurements are first-frame/rebuffer performance by network cohort, origin demand after cache loss, and encoder cost per useful watched minute.”

If the interviewer changes the product to a licensed subscription catalog, add current entitlement and regional/time-window checks before session grants, a DRM/key-service design where required, and rights-aware takedown behavior. The same segment delivery machinery helps, but it does not supply those business authorization guarantees automatically.

Recall the key ideas

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