Loading…
Loading…
Design a video streaming platform like Netflix. Users browse a catalog, and stream high-quality video content on demand across different devices and network conditions.
Content Team
│
▼
[Transcoding Pipeline]
raw video → encode 10 resolutions → upload to CDN
├── H.264 (broad compatibility)
├── H.265/HEVC (4K efficiency)
└── AV1 (best compression, used for 4K+ on supported devices)
Client
│
├── [API Service] → metadata, catalog, recommendations
│
└── [CDN (Open Connect)] → video chunks
│
CDN edge server fetches from S3 origin on cache miss
Open Connect: Netflix's custom CDN with servers inside ISP data centres. This eliminates most transit costs and reduces latency to <20ms for video chunks.
GET /catalog?genre=action&page=1
GET /titles/{titleId}
GET /titles/{titleId}/manifest → returns MPD/M3U8 playlist
(Adaptive bitrate manifest listing all quality levels)
GET /recommendations?userId={id}
GET /playback/resume?titleId={id}&userId={id}
→ { position: 3601, episodeId: "...", deviceId: "..." }
PUT /playback/position
Body: { titleId, position, episodeId, deviceId }
Content metadata (Cassandra + Elasticsearch)
titles: id, name, description, genres[], cast[], rating
episodes: id, title_id, season, episode_number, duration
encoding_profiles: id, title_id, resolution, bitrate, s3_url
User data (MySQL — strong consistency for billing/subscription)
users: id, email, plan, subscription_status
watchlist: user_id, title_id, added_at
watch_history: user_id, title_id, position, last_watched
Recommendations (offline batch job → Redis pre-computed per user)
REDIS: recommendations:userId → List of titleIds
Video is encoded into 10-second chunks at multiple quality levels. The client player (adaptive bitrate algorithm) monitors download speed and switches quality levels seamlessly.
1080p chunk → downloads in 2s (target 10s TTL) → buffer healthy → stay at 1080p
1080p chunk → downloads in 8s → buffer dropping → switch to 720p
Popular new releases are pre-pushed to all edge CDN servers before release. When 22M subscribers hit play at the same time, they all get it from local CDN — the origin sees zero traffic.
Q: Why run a separate control plane and data plane instead of one set of services? A: They have completely different load profiles. The control plane handles small, frequent requests: browsing, authentication, choosing playback servers. It needs low latency and rich business logic, and runs in a few cloud regions. The data plane moves enormous volumes of video bytes, and needs to sit physically close to viewers. Separating them lets each scale and fail independently. A control-plane outage can degrade browsing without stopping streams that are already playing.
Q: How does the system decide which CDN server a client should stream from? A: When a user presses play, the playback service returns a ranked list of candidate servers. It's computed from the client's network location (ISP and region), each server's health and current load, and whether the server actually holds the requested title in the needed encoding. The client uses the first server, measures throughput, and fails over down the list if a server is slow or unreachable.
Q: How much storage does one title need, and why is that acceptable? A: A single title may be encoded into dozens of versions (resolutions × bitrates × codecs), plus audio tracks and subtitles, often several times the size of the source. That storage cost is paid once per title, while bandwidth is paid on every view. More efficient encodings save far more in delivery costs than they cost to store.
Q: What happens during a traffic spike, such as the release of a hugely popular series? A: The spike is predictable, so content is pre-positioned on edge servers before release. The control plane autoscales ahead of time, and non-essential features (some personalization, less critical rows) can be degraded to protect playback. Edge servers absorb the video load, so origin traffic stays modest even with millions of simultaneous viewers.
Q: How do you measure whether streaming quality is good? A: Collect client-side metrics from players: time to first frame, rebuffering ratio (the time spent stalled divided by the time watching), average bitrate, bitrate switches, and playback failures. Aggregate them by device, ISP, region and CDN server. These quality-of-experience metrics drive CDN placement, encoding decisions and alerting, because server-side metrics alone can't see what viewers experience.
Q: How would you design "continue watching" across devices? A: Players send periodic progress heartbeats (for example every 30 seconds, and on pause or exit) to a viewing-history service, which stores the latest position per profile and title in a store partitioned by profile ID. Another device reads that position when it opens the title. Last-write-wins by timestamp is usually acceptable, since exact precision doesn't matter.