Interview Case Studies
Design a Video Streaming Platform
Uploading, transcoding and serving video to every kind of screen, where the bandwidth bill shapes the whole design.
Medium16 min read
By the end of this chapter
- Design a resumable upload path that never streams video bytes through the API servers
- Lay out a transcoding pipeline that parallelises per segment
- Explain adaptive bitrate streaming from the client's point of view
- Show with arithmetic why a CDN is not optional
Clarify the requirements
- Functional: creators upload videos, possibly large and over unreliable connections.
- Functional: uploaded videos are processed into formats and qualities that play on phones, browsers and TVs.
- Functional: viewers watch with quality that adapts to their connection.
- Functional: basic metadata - title, description, view counts.
- Out of scope: recommendations, comments, live streaming. Live is a different design because there is no time to transcode ahead.
- Non-functional: playback starts quickly and rebuffers rarely. This matters more than anything else to viewers.
- Non-functional: processing may take minutes; creators tolerate that.
- Non-functional: original uploads are never lost.
Estimate
Sign in to keep a note here. It is free, and nobody else can see it.
Sign inYou’ve reached the end
What this chapter was for:
- Upload directly to object storage with signed URLs; API servers handle metadata only.
- Transcoding is a pipeline of independent jobs: split, encode each rendition in parallel, package, publish.
- Adaptive bitrate moves the quality decision to the client, segment by segment, based on what its network is doing right now.
- Egress dwarfs everything else, so segments are immutable, cached at the edge, and served from origin only on a miss.