The problem
You are designing a simple video streaming platform where users can upload and watch short educational videos. The platform will initially launch for a single country and is expected to support a moderate user base of students and teachers. If the design is wrong, users could experience slow video loads or failed uploads, leading to poor engagement and negative feedback.
You are the lead backend engineer tasked with designing the core system for video upload and playback.
If your design cannot handle the expected traffic or fails to deliver videos smoothly, users will abandon the platform.
Constraint 1
Uploads must support files up to 100 MB.
Constraint 2
Video playback should start within 3 seconds for 95% of requests.
Constraint 3
The system should store videos for at least 1 year.
Constraint 4
User authentication is required for both upload and playback.
Step 1 · What to build (requirements)
A strong candidate never designs from the one-line brief — they pin down what the system must do (functional requirements) and how well it must do it (non-functional: speed, scale, durability) before drawing anything.
Here is the requirement set this design is built on. Notice how each one is a single, checkable sentence — and how the non-functional ones are measurable, not vibes.
The requirements
| Type | Requirement | Priority |
|---|---|---|
| Functional | Users must be able to upload video files up to 100 MB. | Must have |
| Functional | Users must be able to stream videos they have access to. | Must have |
| Functional | User authentication is required for both uploading and streaming videos. | Must have |
| Functional | The system should store and retrieve basic video metadata (title, uploader, upload date). | Nice to have |
| Non-functional | Video playback should start within 3 seconds for 95% of requests. | Must have |
| Non-functional | Videos should be stored for at least 1 year. | Must have |
What you learn by asking
In an interview these facts are NOT volunteered — the candidate earns them with clarifying questions. These are the answers behind this design.
| If you ask about… | The answer |
|---|---|
| Daily uploads | On average, users upload 1000 videos per day. |
| Average video size | The average video is 50 MB. |
| Peak concurrent viewers | Peak load is 2000 concurrent viewers. |
| Average video length | Videos are about 10 minutes long. |
| Playback bitrate | Streaming uses 1 Mbps per viewer. |
| User base growth | User base is expected to double in 1 year. |
Step 2 · The numbers (back-of-envelope)
Rough arithmetic turns the requirements into engineering decisions: it tells you which parts of the design need scaling machinery and which are trivially easy. Only the order of magnitude matters.
The worked numbers
| Quantity | Answer | How it is derived |
|---|---|---|
| Total video storage needed per year | ~18.25 TB | 1000 videos/day × 365 days × 50 MB = 18,250,000 MB/year = 18.25 TB/year |
| Peak outbound bandwidth for streaming | ~2 Gbps | 2000 viewers × 1 Mbps = 2000 Mbps = 2 Gbps |
Step 3 · The API
Every operation traces back to a requirement — nothing extra, nothing missing.
| Endpoint | Purpose |
|---|---|
| POST /videos/upload | Allow authenticated users to upload a new video file with metadata. |
| GET /videos/{videoId}/stream | Stream the video content to authenticated users. |
| GET /videos/{videoId}/metadata | Retrieve metadata for a specific video. |
The data model
| Entity | Fields |
|---|---|
| Video | id: string (Unique video identifier), title: string (Video title), uploaderUserId: string (User who uploaded), uploadDate: datetime (Upload timestamp), fileUrl: string (Location of video file) |
Step 4 · The architecture
The reference design, with the reason behind every connection. When you practice, you will rebuild this from a palette that includes decoys.
Why each connection exists
- User DeviceAPI GatewayAll user actions go through the gateway for routing and authentication.
- API GatewayVideo ServiceThe gateway passes requests to the backend service.
- Video ServiceVideo StorageThe service saves and retrieves video files.
- Video ServiceMetadata DatabaseThe service manages video metadata.
- Video StorageCDNCDN caches video files for faster playback.
- User DeviceCDNClients stream videos directly from the CDN for low latency.
Step 5 · Defending it (deep dives)
Interviewers close by stress-testing the design. Strong answers follow one shape: which component → what breaks there → the fix and its cost. Here are this problem's probes and the points a strong answer hits:
What bottleneck would occur if the CDN is removed from your design, and how would this affect user experience? Video files would be served directly from storage, increasing latency.. Playback start times would rise, especially for distant users.. Storage service could become overloaded under high concurrent demand..
If the video storage becomes unavailable, what user actions would fail and how could you mitigate this? Uploads and new playback requests would fail.. Existing CDN-cached videos might still play until cache expires.. Mitigation: add storage redundancy or failover mechanisms..
If the number of videos grows 10x, what changes (if any) would you make to the metadata database? May need to scale the metadata database (sharding, replication).. Monitor query performance and add indexing as needed.. Consider adding a metadata cache if read load becomes high..
Tip — Key takeaway
A simple video streaming system must separate metadata and file storage, use a CDN for fast playback, and ensure authentication for all user actions. Even at moderate scale, direct file serving is a bottleneck—CDNs are essential for good user experience. Start with the simplest design, then add components like CDNs as you encounter real bottlenecks.
Common trap — Common mistakes on this problem
Serving video files directly from the backend or storage without a CDN, leading to slow playback and overloaded servers. · Mixing video files and metadata in the same database, which makes scaling and backups harder. · Skipping authentication, which risks unauthorized access and misuse.
You've seen the whole design — now build it yourself
The practice run walks the same five steps, but YOU do the work: gather the requirements, run the numbers, wire the architecture — with an AI interviewer and per-step feedback.