Patterns, Technologies, and Concepts

• Source & Deep Dive

×

Key Takeaways

Requirements

You initially missed low latency video playback startup as an explicit non-functional requirement, but corrected this in your second attempt with a solid quantified target.

• For video streaming platforms, low latency playback startup is a standalone non-functional requirement separate from general availability or network handling. Users expect a video to begin playing within 200-500ms of clicking it, and failing this causes immediate abandonment even if the site is technically ‘up’.

• When stating latency requirements in a system design interview, always quantify them with a specific number like ‘under 300ms to first frame’ rather than describing them qualitatively. This makes the requirement testable and shows you understand what engineers would actually measure and optimize for.

Core Entities

You demonstrated strong entity modeling skills by correctly identifying core YouTube entities and showing good judgment in separating VideoMetadata from raw Video content.

• Separating VideoMetadata from Video is a best practice because metadata like titles, descriptions, and tags are queried frequently and stored in a relational or document database, while raw video binary data is stored in blob or object storage like S3. Mixing them would waste database resources and slow down common queries.

API

You demonstrated strong API design fundamentals, correctly identifying presigned URLs as the right pattern for large file uploads in a video streaming system.

• Presigned URLs let clients upload large files directly to blob storage like S3, bypassing your application servers entirely. This avoids bottlenecks since your servers never touch the raw video bytes, reducing bandwidth costs and server load.

• For video upload endpoints, the server generates a temporary presigned URL and returns it to the client. The client then makes a separate PUT request directly to S3 using that URL. The URL expires after a short time window for security.

High Level Design

You demonstrated a solid grasp of the upload and streaming flows across both attempts, with the main gaps being around how to cleanly model and communicate the distinction between raw uploaded files and processed playback-ready assets.

• A video metadata record should store two separate references: the raw S3 object key pointing to the original uploaded file, and the processed segment URLs pointing to playback-ready assets. Mixing these up makes the system harder to reason about because a raw upload is not directly streamable.

• When returning streaming information to a client, return a manifest file rather than a flat list of all segment URLs. A manifest is a structured document that tells the client what bitrates and segments are available, letting the client lazily fetch segments one at a time instead of receiving every URL upfront.

• In adaptive bitrate streaming, the upload pipeline and the processing pipeline serve different purposes. The upload pipeline stores the raw video file. The processing pipeline transcodes that raw file into multiple bitrates and short segments that clients can actually stream. These are two distinct sets of stored assets with different S3 locations.

Deep Dives

You demonstrated solid understanding of adaptive bitrate streaming and resumable uploads, but initially missed the write path for cross-device resume and needed a couple of attempts to land on a complete playback progress solution.

• Cross-device resume requires two separate flows: a write path where the client sends progress updates to the server, and a read path where a new device fetches the saved position before starting playback. Without both, the feature does not work end to end.

• Updating playback progress only on pause or exit is not enough. If the app crashes or the browser closes unexpectedly, that event never fires. The stronger pattern is to combine periodic writes every 30 to 60 seconds with event-driven writes on pause and exit, so progress is never far behind what the user actually watched.

• Store playback progress as both the last segment index and a timestamp or byte offset within that segment. Storing only the segment means the user resumes several seconds before where they actually stopped, which feels imprecise when segments are 5 to 10 seconds long.

• For very short-form content like YouTube Shorts, skipping resume state entirely is a valid design decision. The write overhead and added complexity are not worth it when the video is short enough that restarting from the beginning is acceptable.