Loading system design…
Loading system design...
Design a video streaming platform like YouTube that supports video upload, processing (transcoding to multiple resolutions/codecs), adaptive bitrate streaming, personalised recommendations, live streaming, and content moderation — all at planetary scale.
| Metric | Value |
|---|---|
| Daily active users (DAU) | 1 billion |
| Hours of video uploaded per minute | 500 hours |
| Videos watched per day | 5 billion |
| Total hours watched per day | 1 billion hours |
| Bandwidth served per day | 1+ exabyte (1,000+ petabytes) |
| Total videos stored | 800+ million |
| Storage for all video variants | 500+ petabytes |
| Transcoding variants per video | ~20 (5 resolutions × 4 codecs) |
| Average video duration | 7 minutes |
| CDN edge PoPs | 2,000+ (including ISP-embedded GGC caches) |
Upload videos: users upload video files (up to 12 hours / 256 GB); system ingests, processes, and stores them
Stream/playback videos: users watch videos with adaptive bitrate streaming (auto-adjusts quality based on bandwidth) with near-zero buffering
Transcode uploaded videos into multiple resolutions (144p, 360p, 720p, 1080p, 4K) and codecs (H.264, VP9, AV1) for device/bandwidth compatibility
Generate video metadata: thumbnails (auto-generated + custom upload), duration, file size, content tags, and captions/subtitles
Video feed/homepage: personalised video recommendations based on watch history, likes, subscriptions, and trending content
Engagement: users can like, dislike, comment, and subscribe to channels; view count updates in near real-time
Search: full-text search over video titles, descriptions, tags, and auto-generated captions
Support resume playback: if user pauses and returns later, continue from the last watched position
Live streaming: creators can broadcast live video to viewers in real-time with < 5 second latency
Content moderation: detect policy-violating content (copyright, NSFW, violence) during upload processing and flag for review/removal
Non-functional requirements define the system qualities critical to your users. Frame them as 'The system should be able to...' statements. These will guide your deep dives later.
Think about CAP theorem trade-offs, scalability limits, latency targets, durability guarantees, security requirements, fault tolerance, and compliance needs.
Frame NFRs for this specific system. 'Low latency search under 100ms' is far more valuable than just 'low latency'.
Add concrete numbers: 'P99 response time < 500ms', '99.9% availability', '10M DAU'. This drives architectural decisions.
Choose the 3-5 most critical NFRs. Every system should be 'scalable', but what makes THIS system's scaling uniquely challenging?
The complete explanation is included with Career and All Access. Compare it with your approach once you’ve worked through the problem.
Your system-design submission history is available after you sign in.
Sign In