SysPad › Examples › Design YouTube (upload + playback)
Design YouTube (upload + playback)
Upload → original storage → a transcoding-queue-driven worker pool (multi-stage DAG: codecs, resolutions, thumbnails) → transcoded storage + a completion handler updating metadata, with playback served from CDN.
The upload and transcoding pipeline, plus the CDN-served playback read path - two very different traffic shapes on one system.
- Load: 50 req/sec
- First to saturate: Transcoding Workers
- Estimated cost: $4,366k/mo
How it works
- Original Storage
- The raw uploaded file, stored once. Landing it here and returning fast is what lets the slow transcoding happen asynchronously behind a queue.
- Transcoding Workers
- Stands in for a transcoding-server DAG: split audio/video, encode each codec/resolution/bitrate variant, watermark, thumbnail. Fanned out across a large Batch pool because each job is minutes long.
- CDN
- Playback front door. Nearly all watch traffic is served from the edge cache; only cold segments fall through to transcoded storage as the origin.
Request flows
Upload a video
- Content Creator
- DNS
- Load Balancer
- Upload API
- Original Storage
- Transcoding Queue
- Transcoding Workers
- Transcoded Storage
- Completion Queue
- Completion Handler
- Metadata DB
Watch a video
- Viewer
- CDN
Lessons for this architecture
- Modelling users and traffic entry points
- How Route 53 works
- How Application Load Balancer works
- How ECS Fargate works
- How S3 works
- How SQS works
- How AWS Batch works
- How AWS Lambda works
- How DocumentDB works
- How CloudFront works
Worked step by step
The same interview question, built up one twist at a time, with a simulation at each stage.