YouTube on mobile is the canonical “design a video app” interview. Three billion users, infinite catalog, every device on earth. The interview tests your ability to balance playback latency, network bandwidth, decoder constraints, and the realities of someone watching a 4K video on a 5-year-old Android over LTE.
Functional requirements
- Browse a personalized feed of videos. The client prefetches thumbnails and often the first segment of a likely tap, so feed ranking quality feeds directly into how fast playback starts.
- Search and play videos on demand. Interviewers watch the tap-to-first-frame path here — autocomplete, result thumbnails, and warming a nearby CDN edge before the user commits to a video.
- Adaptive bitrate streaming based on network. This is the highest-signal part of the design; be ready to name a concrete algorithm and defend the tradeoff between buffer health and bitrate.
- Subtitles and captions in multiple languages. Cheap to serve but easy to get wrong on timing and language selection; keep them as side files fetched only when the viewer picks one.
- Offline downloads for Premium users. This raises DRM, per-device encryption, and expiry questions — treat it as a storage and licensing problem, not just a bulk download.
- Background audio playback. Tests whether you know the platform lifecycle: keeping the audio stream alive while the video decoder and the screen go to sleep.
Non-functional
- Time-to-first-frame under 1 second on good network
- Smooth playback without rebuffer events at 99th percentile
- Reasonable cellular data usage
Architecture
Three components: player, manifest fetcher, buffer manager.
The video manifest
YouTube uses DASH (and HLS for Apple devices). When a user taps a video:
- Client fetches a manifest (a few KB) describing all available bitrates and codecs
- Client picks the appropriate variant for the device + network
- Client requests segments (typically 2–4 seconds each) and feeds the decoder
Adaptive bitrate (ABR)
The ABR algorithm decides which bitrate to use for the next segment based on:
- Recent download throughput (bandwidth estimation). Estimated from how fast the last few segments arrived. Interviewers probe how you smooth noisy samples so one unusually fast or slow segment doesn’t swing the decision.
- Buffer occupancy (how much video is already downloaded). A deep buffer lets you risk a higher bitrate; a shallow one forces caution. This is the signal that best prevents rebuffering, which is why hybrid algorithms weight it heavily.
- Device capabilities (screen size, decoder support). No point streaming 4K to a 1080p phone or a codec the hardware decoder can’t handle, so cap the bitrate ladder to what the device can actually render.
- User preferences (data saver, “always HD”). Explicit overrides beat the algorithm: data saver pins a low ceiling, “always HD” forces the top variant regardless of the bandwidth estimate.
Algorithms range from BBA (buffer-based) to MPC (model predictive control). Industry standard: a hybrid that prefers buffer health over bitrate aggression.
Captions and subtitles
Captions arrive as a separate WebVTT or TTML file. The renderer overlays them on the video at appropriate timestamps. Multiple languages are downloaded only when selected.
Auto-generated captions are produced server-side and served on demand. Mobile app does not run ASR locally.
Background audio
YouTube Premium allows audio-only playback when the screen is off. Implementation:
- iOS: AVAudioSession with playback category, declare background audio capability
- Android: foreground service with media notification, MediaSession API
The video decoder is paused; the audio stream continues.
Offline downloads
Download manager fetches all segments at the chosen resolution, encrypts with a per-device key, stores locally. Downloads are subject to TTL re-validation; if offline too long, downloads expire.
Battery and data
- Default to 720p on cellular for most users. This caps data spend without a visible quality hit on a phone-sized screen; viewers on Wi-Fi or who opt in get higher resolutions.
- Pause prefetch when battery low. Prefetching burns radio and CPU on video the user may never watch, so back it off below a battery threshold and lean on a smaller buffer.
- HEVC and AV1 codecs save bandwidth where supported, but require more CPU/battery to decode
Frequently Asked Questions
Why does playback sometimes stall right after start?
The ABR may have over-estimated bandwidth from the first segment. Modern algorithms use a conservative initial estimate and ramp up.
How does YouTube reduce time-to-first-frame?
Aggressive prefetch of the first segment when a thumbnail is highly likely to be tapped, server-side video transcoding for fast-start MP4, and CDN edges close to the user.
What is the right segment size?
Tradeoff: smaller segments = faster ABR adaptation but more HTTP overhead. 2–4 seconds is the industry default. Live streams use shorter (1–2s) for low latency.
Keep sharpening your system design:
