Study Notes
Note

Design a YouTube Mobile Client

Getting video to start fast and never stall — on a billion phones, across every network from fiber to one flickering bar.

12 min read
Mobile System Design · Chapter 09

Getting video to start fast and never stall — on a billion phones, across every network from fiber to one flickering bar.

🧭
How to read this

Scope and API (§1–2) frame a consumption-only client; the architecture (§3) makes clear the CDN does the heavy lifting. The deep dives are the substance: adaptive streaming that survives changing networks (§4), intelligent feed prefetching (§5), and mobile-native player touches (§6). Anything marked [+] is context added beyond the source chapter; the rest is a rewrite. Diagrams are original.

01

Consumption, not creation#

The first scoping call narrows an enormous product to something tractable: video consumption only — browsing and playback. No uploads, no live streaming, no likes/comments/playlists. And crucially, playback rides an existing adaptive protocol (HLS or DASH) rather than one built from scratch.

Functional requirements#

  • Browse recommended videos in a home feed.
  • Watch with a feature-rich player: play/pause/seek, quality (360p, 720p…), subtitles, alternate audio.
  • Prefetch feed data so content appears instantly.

Non-functional requirements#

  • Scalability — ~1 billion daily active users, every network from fast Wi-Fi to spotty cellular.
  • Performance — smooth scrolling and playback, efficient delivery across device types.
  • Availability — uninterrupted access, multi-language, global.
📱
Two screens

The Home screen (tailored recommendations) and the Video Player screen (the selected video with controls). Everything below serves one of these two.

02

An API that fetches only what it needs#

Client-server calls use REST over HTTP with JSON — simple, universally supported. At this scale, gRPC with Protocol Buffers would serialize more compactly, but REST is chosen for familiarity. The design borrows from the real YouTube Data API, which has one instructive twist.

✂️
The part parameter — GraphQL's benefit without GraphQL

A Video resource is heavy: metadata, view counts, content restrictions, playback info. No mobile screen needs all of it. The part parameter lets the client name which field groups it wants — snippet for titles/thumbnails, statistics for view counts — so responses carry only what's used. [+] It's coarser than GraphQL's field-by-field selection (you pick from predefined sets, not arbitrary fields), but it kills over-fetching with none of GraphQL's added complexity — and on mobile, every byte counts.

The endpoints#

  • Popular feed (signed-out home): GET/youtube/v3/videos?part=snippet&chart=mostPopular&maxResults=20&regionCode=US
  • Video details (on tap): GET/youtube/v3/videos?id=VIDEO_ID&part=snippet,player,contentDetails,statistics — metadata, playback info, and engagement in one call.
  • Playback: GET…/videos/playback?codecs=…&protocols=…&language=…&subtitles=… → a streaming manifest (DASH or HLS) tailored to the device, plus subtitle options.
🎬
Why an internal playback endpoint

Third-party apps must use YouTube's IFrame Player API, but as YouTube's own client, this app feeds manifests straight to the platform's native video player. [+] A manifest is a small text file listing the available quality renditions and the URLs of each media segment — the map the player reads to stream adaptively.

03

The client and the CDN behind it#

Same layered client as the other case studies, but with one component doing outsized work: the CDN. Video bytes never come from the origin — they come from a cache node near the user. The API Gateway and Backend handle metadata and routing; the CDN handles the streams and thumbnails.

CLIENT UI LAYER Home screen Video Player screen + Player UI ImageLoader DATA LAYER Browsing repo Video repo History repo Network Dispatcher SERVER-SIDE API Gateway routing · auth Backend CDN video · thumbnails (edge) media stream
Figure 1 — Metadata flows through the gateway; the player and image loader pull the heavy media straight from the CDN edge.
🌐
Why the CDN is non-negotiable — and why giants build their own

CDNs cut latency (content from a nearby node, not a distant origin), absorb load (millions streaming the same video hit many edge servers, not one), and cut cost (fewer trips to origin). But at scale the CDN bill itself becomes huge — so Netflix built its own, Open Connect, and others place servers directly inside ISP networks to cut delivery cost and improve quality.

The client's data layer runs Browsing, Video, and History repositories, each with a remote source over the Network Dispatcher. Prefetching adds more components later.

04

Streaming that adapts to the network#

Streaming is not downloading. Instead of waiting for a whole file, the player pulls the video in small segments: playback starts after the first few arrive, more load in the background, played segments are freed, and — the key part — quality adjusts to the connection. That model suits mobile perfectly: low memory, any length, resilient to changing networks.

The protocols#

ProtocolWhat it isFit
HLS ✓Apple's HTTP chunked streaming; WebVTT subtitle tracks in the .m3u8 playlist.Ubiquitous, strong on Apple; supports adaptive bitrate.
DASH ✓Open standard, codec-agnostic; WebVTT/TTML tracks in the .mpd manifest.Flexible; strong outside Apple; supports adaptive bitrate.
CMAFA unified container that lets one set of segments serve both HLS and DASH.Cuts storage and duplication.
WebRTC · SRT · RTSP · RTMPReal-time / low-latency / legacy protocols.Conferencing, ingest, older systems — not the main VOD path.

HLS and DASH lead for apps like YouTube, Twitch, and Netflix; both do adaptive bitrate streaming, with low-latency variants (LL-HLS, LL-DASH) when delay matters. Most platforms ship several — YouTube supports HLS, DASH, RTMP, and RTMPS so clients can pick.

📝
Interview altitude

You don't need the low-level protocol internals. What matters: different protocols support different formats and players, and that shapes your architecture choices.

How adaptive bitrate works#

Each video is encoded at several qualities (480p / 720p / 1080p), every quality is split into the same short segments (2–10s), and the player picks a quality per upcoming segment based on live conditions. Because each choice only affects the next segment, the system reacts immediately.

SAME VIDEO, THREE ENCODINGS 1080p 720p 480p player's per-segment choice → bandwidth high drops recovers
Figure 2 — The player climbs to 1080p on good bandwidth, drops to 480p the instant it falls to avoid a stall, then recovers — one segment at a time.

The player decides using download speed, buffer level, and CPU/GPU — in practice a buffer-based or hybrid algorithm. [+] On device, use the native players: ExoPlayer (Android) and AVPlayer (iOS) — they handle HLS/DASH with hardware decoding and deep platform integration.

🔤
Subtitles and audio are separate tracks

HLS and DASH keep video, audio, and text as independent, time-synced streams. That cuts bandwidth (text is tiny), enables multi-language without duplicating video, meets accessibility needs, and lets captions update without re-encoding video.

🖼️
Seek-preview thumbnails aren't in the protocol

Two approaches. Sprite sheets pack many thumbnails into one image (fewer requests, but you pre-generate and store extra assets). Adaptive low-res frames — YouTube mobile's choice — reuse the streaming stack to fetch actual 144p/240p frames at the scrubbed timestamp: real motion, no extra storage, accurate previews.

⚙️
The mobile streaming tax

Memory: adaptive buffer sizing, frame recycling, degrade under pressure, release on background. Battery: lower quality on low battery, hardware decode, pause/suspend when hidden (Android Battery Saver API, iOS low-power notifications). Network: bandwidth adaptation, retries with exponential backoff + jitter [+] (randomized delay so retries don't thundering-herd), pre-download on Wi-Fi, connection-aware buffering. Advanced: prioritize audio continuity, predictive buffering, cache subtitle tracks.

🔍
In the wild

Reddit customized ExoPlayer for short videos (MP4 under 45s, tuned caching/buffering), cutting load times and rebuffering. Netflix uses shot-based encoding for better 4K at lower bitrate, a Unicode subtitle pipeline, and studio-quality audio work.

05

Prefetching the feed intelligently#

Users expect the feed to be there the instant they open the app. Prefetching loads feed data ahead of time — but it spends network, battery, and memory, so when to prefetch is the whole game.

StrategyTriggerTrade-off
Time-basedFetch on a fixed interval.Simple, predictable; wastes data, ignores behavior.
Event-basedFetch on app foreground/background.Aligns with usage; may miss optimal moments.
Intelligent ✓Combine device state, usage patterns, relevance, resources.Best UX and efficiency; most complex, needs tuning + monitoring.
🎯
Decision: intelligent prefetching

At a billion users with rich signals, decide from the client using device state (charging, network type), user patterns (typical open times), content relevance, and resources (battery). A remote configuration system [+] lets the backend tune client behavior — how much to prefetch, the interval, whether cellular is allowed — without an app update.

The backend scores each recommendation with a relevanceScore (0–100, how well it matches the user) and a ttl (how long it stays valid). Scores aren't static — when preferences shift, the backend updates them and the client refreshes its cache.

OS scheduler WorkManager 1 Prefetching Service Device Monitor battery? network? 2 Remote source + Dispatcher 3 Recommendations repository 4 Browsing repo → home feed 5
Figure 3 — The OS wakes the service, the Device Monitor gates on conditions, and only then does a sync refresh the recommendations that fill the feed.

A background scheduler runs it — Android's WorkManager (built-in Wi-Fi/charging constraints), iOS's Background Tasks framework (earliestBeginDate plus your own condition checks). Both may delay or batch tasks, so the implementation must handle that gracefully. A feedback loop then adapts: prefetch more during high engagement, pause during quiet periods.

📉
Prefetch responsibly, and measure it

Restrict to Wi-Fi by default (opt-in cellular), pause under ~20% battery, do less on low-end devices, cap the cache and downsample thumbnails, clear on memory pressure. Then prove it works: track time-to-first-recommendation, engagement with prefetched vs not, percentage of prefetched videos actually watched, and bytes prefetched but never viewed — the clearest measure of waste.

🔍
In the wild

Facebook's app watches an in-memory pool of videos as you scroll; when it drops below a threshold, it fetches and ranks fresh personalized candidates with user signals, then caches them for smooth playback.

06

Player experiences built for mobile#

A common follow-up: how do you make the player feel native? Three features, meant to work as one system.

Gesture controls#

Buttons and sliders feel clunky on a small screen. Direct gestures — swipe to seek, vertical drags for volume and brightness — feel immersive. Three pieces: a GestureDetector interprets touch (swipe/tap/pinch), a VideoControlHandler turns gestures into player commands, and visual feedback confirms what happened. The hard parts are disambiguating similar gestures, resolving overlaps, and accessibility for users who can't perform them.

Background audio#

Music, podcasts, and news are valuable audio-only. On backgrounding: listen for lifecycle events, release video rendering while keeping audio, and switch to audio-only streams to save data. Android uses a foreground service with a media notification (Jetpack Media3); iOS uses AVAudioSession with the right category. Respect preferences — an on/off toggle, cellular audio-only mode, and often a premium-only gate.

Picture-in-Picture#

PiP floats the video in a small window while the user does other things. Native APIs: iOS AVPictureInPictureController, Android enterPictureInPictureMode. Optimize it: auto-enter on home/app-switch, simplify controls to play/pause/close, drop quality to save bandwidth, pause non-essential work, and restore exact state on return.

🧩
They only pay off if they interoperate

Gestures should behave the same full-screen or in PiP; switching to background audio must preserve playback position so the user resumes seamlessly. The value is in the unified experience, not the three features in isolation.

07

Recap#

Consumption onlyBrowse + play; existing HLS/DASH, no creation or live.
The part parameterField-group selection kills over-fetching without GraphQL's complexity.
CDN does the heavy liftingMedia streams from the edge, bypassing the gateway; giants build their own.
Segments, not filesStart fast, load ahead, free played segments, adjust quality.
Adaptive bitrateSame video at many qualities; pick per segment on live bandwidth.
Native playersExoPlayer and AVPlayer for hardware decode and platform integration.
Intelligent prefetchGate on device signals + remote config; measure bytes wasted.
Mobile-native touchesGestures, background audio, and PiP as one coordinated system.
💡
The single idea underneath it all

A streaming client's whole job is continuous adaptation to conditions it doesn't control — the network, the battery, the device. Adaptive bitrate adapts quality to bandwidth per segment; intelligent prefetch adapts fetching to device state; the player adapts buffers and decoders to what's available. Nothing is fixed up front; everything is a decision made fresh, moment to moment, to keep the video playing.

08

Further reading#

All 37 links below were fetched and confirmed live on 24 August 2026, grouped by topic.

Scale & APIs

  1. YouTube demographicsThe 2.5-billion-user, 80+-language scale that motivates the design.
  2. YouTube statisticsMobile's 70%+ share of watch time — why the mobile experience is the priority.
  3. YouTube Data API — videosThe real API behind §2, including the part parameter.
  4. Video resource definitionThe rich metadata model that field selection trims down.
  5. YouTube IFrame Player APIWhat third-party clients must use — and what the internal client bypasses.
  6. YouTube ingestion protocol comparisonRTMP/RTMPS/HLS/DASH compared — why platforms support several.

Streaming protocols & ABR

  1. Netflix Open ConnectNetflix's own CDN — the "build your own delivery" strategy.
  2. HLSApple's chunked-over-HTTPS protocol.
  3. DASHThe codec-agnostic open-standard counterpart.
  4. CMAFThe unified container that lets one set of segments serve HLS and DASH.
  5. WebRTCUltra-low-latency, conferencing-oriented — the real-time end of the spectrum.
  6. SRTSecure reliable transport, often used at ingest.
  7. RTSPAn older real-time control protocol.
  8. RTMPThe legacy Flash-era ingest protocol still used for live.
  9. Streaming protocols, how to chooseA practical protocol-selection guide.
  10. Streaming protocols explainedA broad protocol survey with latency/security trade-offs.
  11. Adaptive bitrate streamingThe core technique behind §4's Figure 2.

Players, thumbnails & optimization

  1. ExoPlayer (Media3)Android's native adaptive player.
  2. AVPlayeriOS's native player.
  3. Texture atlasThe sprite-sheet concept for packed seek thumbnails.
  4. Sprite sheets for previewsA how-to on the sprite-sheet thumbnail approach.
  5. Reddit — improving ExoPlayer playbackA deep, metric-driven account of caching, buffering, and prefetch tuning.
  6. Netflix — shot-based 4K encodesBetter quality at lower bitrate via per-shot encoding.
  7. Netflix — timed text pipelineScalable subtitle/caption processing across languages.
  8. Netflix — high-quality audioDelivering studio-quality audio to viewers.

Prefetch, background & PiP

  1. Android WorkManagerConstraint-aware background scheduling for prefetch.
  2. iOS Background TasksThe iOS side of background prefetch scheduling.
  3. Inside Facebook's video deliveryThe scroll-triggered, pool-based prefetch model from §5.
  4. Facebook Feed recommendationsHow relevance scoring ranks feed content.
  5. Android foreground servicesKeeping background audio playback alive.
  6. Jetpack Media3The modern Android media APIs for playback and notifications.
  7. AVAudioSessioniOS background-audio configuration.
  8. Picture-in-PictureThe PiP concept.
  9. AVPictureInPictureControlleriOS PiP API.
  10. Android Picture-in-PictureAndroid PiP API.
  11. Live streamingBackground for the wrap-up's live extension.
  12. PlaylistBackground for the wrap-up's playlist extension.

Rewritten in original wording from ByteByteGo's Mobile System Design Interview — Chapter 9, "YouTube app." All diagrams are original SVG, not reproductions of the source figures.

[+] marks context added beyond the source. Links were verified live on 24 August 2026.