Loading...
High availability — if YouTube goes down users can't watch or upload videos
Low latency — video should start playing within seconds, search results under 100ms
Scalability — handle billions of video views and millions of uploads daily
Eventual consistency — okay if view counts and search index take a few seconds to update
Estimate the scale of the system. Consider daily active users, read/write ratio, storage requirements, bandwidth, and any relevant QPS calculations...
Define the APIs expected from the system. This is your chance to analyze and define the read and write paths so that you can come up with the high-level design...
POST /upload
input: { user_id, video_file, title, description, tags }
output: { video_id, status: "processing" }
GET /videos/:video_id
input: { video_id, resolution }
output: { cdn_url, title, description, view_count }
GET /search
input: { query, page }
output: { list of video_ids, titles, thumbnails }
POST /videos/:video_id/like
input: { user_id }
output: { like_count }
POST /videos/:video_id/comments
input: { user_id, content }
output: { comment_id, created_at }
GET /videos/:video_id/comments
input: { page }
output: { list of comments }
GET /feed
input: { user_id, page }
output: { list of recommended videos }
GET /analytics/:video_id
input: { time_range }
output: { view_count, likes, watch_time by day/week/month }
Describe the overall system architecture. Identify the main components needed to solve the problem end-to-end. Use the diagramming tool to create a block diagram.
"The client hits the rate limiter and API gateway which handles auth and rate limiting before passing requests to the load balancer. The load balancer routes to five services — upload server, streaming server, search server, likes and comments server, and analytics server.
When a user uploads a video the upload server stores the raw file in S3 and drops a metadata event into Kafka. The transcoding service reads the raw video from S3, converts it into multiple resolutions, and stores all versions back in S3. The CDN then caches all versions so users globally get fast playback. The worker consumes the Kafka event and writes metadata to the database and Elasticsearch so the video is searchable.
When a user watches a video the streaming server checks the video cache first for metadata. On a miss it queries the database, generates a signed CDN URL based on the user's device and connection, drops a view event into Kafka, and returns the CDN URL to the client. The client streams directly from the CDN.
Search requests hit the search server which checks the popular search cache first. On a miss it queries Elasticsearch which returns matching video IDs and metadata. Results are stored in cache for repeated queries.
Likes, comments, and analytics events all go through Kafka and are processed asynchronously by the worker server which writes to the database. This keeps the system highly available under heavy traffic."
Define the data model. Identify the main entities, their attributes, and relationships. Consider the choice of database type (SQL vs NoSQL) and justify your decision based on access patterns...
Deep dive into 2-3 key components. Explain how they work, how they scale, discuss tradeoffs, capacity, and any relevant algorithms or data structures.
"The transcoding service is the most unique component of this system. When a video is uploaded it exists only as a raw file in S3. The transcoding service reads that file, converts it into multiple resolutions — 1080p, 720p, 480p, 360p — and writes all versions back to S3. The CDN then caches every version. When a user plays a video the streaming server picks the right resolution based on their device and network speed. This is called adaptive bitrate streaming — if your connection drops, the player automatically switches to a lower resolution version from the CDN without buffering. Without transcoding every user would get the same raw file regardless of their connection quality.
The worker server has two jobs. First it writes all metadata to the database — video ID, title, uploader, CDN URLs, timestamps. Second it writes searchable fields to Elasticsearch — title, description, tags, video ID. These happen simultaneously from the same Kafka event. This means Elasticsearch is always in sync with the database without either one talking to the other directly.
Elasticsearch is a dedicated search index optimized for full text search. Unlike a regular database that would do a slow scan across billions of rows looking for titles containing 'funny cats', Elasticsearch maintains an inverted index — a pre-built lookup of every word to every video that contains it. A search query returns results in milliseconds regardless of how many videos exist. The popular search cache sits in front of it so repeated common searches never hit Elasticsearch at all.
The analytics server drops every view, like, and comment event into Kafka without touching the database directly. This means even during a viral video receiving millions of simultaneous views, the database never gets hit directly. The worker batches these events and writes them in bulk, keeping the database load manageable while ensuring no analytics data is ever lost."