Design Netflix

Requirements: what to ask before drawing anything

"Design Netflix" covers a sign-up funnel, a profile picker, a browse page, search, a title detail view, a video player, downloads, and a TV app. That is far too much for 45 minutes. Spend the first five minutes agreeing which surfaces get depth. Ask the questions whose answers change the design, and say out loud what each answer changes.

A useful order: surfaces (which screens), devices and inputs (mouse, touch, remote), content and scale (how many rows, how many titles, how long the videos are), and rules (content protection, kids, search engines). The table shows the answers this guide assumes.

Functional requirements

• Pick a profile after sign-in, with an optional 4-digit lock on a profile.
• Show a browse page: a large hero ("billboard") at the top, then rows such as Continue Watching, Trending Now, and Because You Watched X.
• Scroll the page down through rows, and scroll each row sideways through its titles, with mouse, touch, keyboard, or remote.
• On hover (desktop) or focus (TV), enlarge the card and play a muted preview after a short delay. Members can turn previews off.
• Open a title's details: synopsis, cast, rating, seasons and episodes, and similar titles.
• Play a title with adaptive quality, subtitles, audio languages, skip intro, and a countdown to the next episode.
• Resume from the last position on any device, and keep Continue Watching up to date.

Non-functional requirements

• Startup time: press play to first frame under 2 seconds on a good connection. Viewers notice waits of a few seconds, and some leave.
• Smooth playback: rebuffering (the video pausing to load) under 0.5 percent of watch time.
• Smooth browsing: scrolling and focus moves at 60 frames per second on desktop and at least 30 on a slow TV, with each focus move answered within 100 ms.
• Memory: TV apps may get only a few hundred megabytes. Thousands of decoded images would not fit.
• Accessibility: full keyboard and screen reader support on the web, captions on every title, and previews that respect reduced motion.
• Isolation: one profile never sees another profile's rows, history, or cached data.

Out of scope, and why

• Offline downloads: Netflix offers downloads only in its mobile apps, not on the web. Mention that the native apps store encrypted files with an offline license, then move on.
• The recommendation model: the backend ranks rows and titles. The client only shows what it gets and reports what the member did.
• Encoding and the CDN (content delivery network, the servers that hold the video files near members): the server side prepares every title at many qualities. We care about how the client picks among them.
• Sign-up and payments: a normal form flow with no special frontend problem.

What makes Netflix hard

It's tempting to call Netflix "YouTube with a subscription". The YouTube guide already covers a watch page, a basic adaptive player, and a mini-player. Netflix differs in five ways, and each one drives a later chapter.

1. The browse page is a grid of grids. YouTube's home is one long list of cards. Netflix's is a vertical list of rows, and each row is its own horizontal list. Both directions need windowing, and the two interact: when you scroll down, a whole row of 75 cards enters the screen at once.
2. The browse page is mostly images. A desktop screen shows about 6 rows of 6 cards, so 36 images plus a full-width hero, all visible together. Every pixel of that artwork was picked for this member. Image bytes, decode time, and memory are the main costs, not JavaScript.
3. Previews play video while you browse. Hovering a card for a moment starts a muted trailer. Done carelessly, a member sweeping the mouse across a row starts 10 video downloads in 2 seconds. Previews are the most wasteful feature on the page unless they are cancelled well.
4. The main device is a TV with a remote. Netflix has said for years that most viewing happens on TVs. A remote has four arrows, OK, and Back. There is no pointer and no scroll wheel, so the app itself must decide where focus goes for every key press, and it must do it on a CPU much slower than a laptop.
5. Every title is protected. Licensed films and shows require DRM. The player cannot just fetch a file: it must fetch encrypted segments, ask a license server for keys, and hand both to the browser's protected decoder. Which DRM system a browser supports decides the best quality it may play.

Two more things raise the bar. Members are paying, so a stall or a slow start feels like a broken product, and they can cancel any month. And a household shares one account across several profiles and devices, so state like "where did I stop?" must follow the profile, not the device.

The browse page: rows of rows

Start with the naive version, because it's what most people build first. Fetch the whole page as JSON, then render 40 row components, each mapping over its 75 titles to an img inside a card. Add loading="lazy" to the images and call it done.

Count what that costs. A card with its image, title overlay, progress bar, and hover controls is about 15 DOM nodes. 3,000 cards is 45,000 nodes before the hover card or the hero. Style and layout work grows with the node count, so every hover that changes a class can trigger seconds of style recalculation on a TV.

The JSON for 3,000 titles with artwork URLs, ratings, and tags is around 1 to 2 MB, and the server must rank every row before it can send the first byte. Native lazy loading helps with image downloads, but the nodes, the layout, and the payload are all still there.

Fixed geometry makes the math cheap

Netflix rows don't scroll freely like a phone carousel. On desktop they move by a page: an arrow at the edge shifts the row by exactly the number of visible cards.

That choice is not only visual. It means the row's state is one integer, the page index, and the visible cards are always page * perPage to page * perPage + perPage - 1. The number of cards per page comes from the viewport width, so card width is computed, not measured.

function cardsPerPage(viewportWidth: number): number {
  if (viewportWidth >= 1400) return 6;
  if (viewportWidth >= 1100) return 5;
  if (viewportWidth >= 800) return 4;
  if (viewportWidth >= 500) return 3;
  return 2;
}

function renderedRange(page: number, perPage: number, total: number) {
  const first = Math.max(0, (page - 1) * perPage);
  const last = Math.min(total - 1, (page + 2) * perPage - 1);
  return { first, last }; // up to 3 pages, e.g. 18 cards at 6 per page
}

The row's track is one element moved with transform: translateX(...), so a page change is a compositor animation, not a layout. Cards inside the track are absolutely positioned at index * cardWidth, so cards entering or leaving the rendered range never shift their neighbours.

Remember each row's position after it unmounts

When a row scrolls out of the vertical window, its component unmounts. If the member had paged that row to page 3 and scrolls back up, it must still be on page 3. So the page index can't live in the row's own state.

Keep a small map in the browse page's store: row id to page index (and, on TV, row id to the focused card index). It's a few bytes per row and it survives unmounting. The same map is saved to history.state so the Back button from a title's details restores both the vertical scroll and every row's page.

Loading rows lazily

The first response carries the hero and the first 6 to 10 rows, each with only its first two pages of titles (about 12 per row). That's enough to fill the screen and the first page move.

A sentinel (an empty marker element) a few rows below the last loaded row is watched with an IntersectionObserver using a rootMargin of about one screen height. When it comes into range, the client asks for the next chunk of rows. Inside a row, when the member reaches the second-to-last loaded page, the client fetches the next page of that row's titles.

Placeholders matter. A row that is known but not yet loaded renders at its final height with grey card shapes, so the page never jumps.

If a row fails to load, retry once with backoff, and if it still fails, remove the row quietly rather than show an error in the middle of the page. A browse page with 39 rows is fine. A browse page with an error box is not.

Artwork: sizes, formats, and personal choices

The browse page is mostly pictures, so image decisions decide how it feels. The naive approach is one artwork file per title, say a 1280 by 720 JPEG of about 150 KB, used everywhere: in cards, in the hover card, and in the details view.

Work out the cost on a desktop. About 36 cards are visible, so the first screen downloads 36 times 150 KB, around 5.4 MB, before the hero. On a 10 Mbps connection that's over 4 seconds of images.

Memory is worse. A decoded image takes width times height times 4 bytes, so 1280 by 720 is about 3.7 MB in memory. With 150 cards rendered, that's over 500 MB of decoded pixels. A TV app with a few hundred megabytes in total would crash or start dropping frames.

Now the right size. At 6 cards per row on a 1920-pixel-wide screen, each card is about 300 CSS pixels wide, so a 341 by 192 image is enough at a device pixel ratio of 1. In WebP or AVIF that's roughly 10 to 20 KB, and decoded it's about 260 KB.

The first screen drops to well under 1 MB, and 150 rendered cards hold about 40 MB of pixels. Same picture, more than ten times cheaper.

The hero is the LCP element

The large billboard at the top is almost always the Largest Contentful Paint element. Give its image fetchpriority="high" and do not lazy load it. Keep the hero's trailer for later: the poster image paints first, and the trailer starts only after the page is idle and the member hasn't scrolled away. Cards below the first screen get loading="lazy", and cards in the first two rows load normally so they don't wait for layout.

Decoding and placeholders

When a row pages, 6 new images can appear at once. Decoding them on the main thread can drop frames during the slide. Two habits help.

First, prefetch and call img.decode() on the next page's images while the member is still looking at the current page, so the slide shows pixels that are already decoded. Second, give every card a placeholder colour sent in the API (a dominant colour per artwork), so a card that isn't ready yet looks like a tinted shape, not a white hole.

Personalized artwork

Netflix has written publicly about choosing different artwork for the same title for different members, picking among several images with a contextual bandit model (a kind of algorithm that learns from which choices lead to plays). A member who watches a lot of romance might see a romantic scene for a film, while another sees its lead actor. The exact model and signals are Netflix's own; what matters for the frontend is how such a system shapes the client.

• The server chooses, the client shows. Each title in a row arrives with an artworkId and its URLs. The client never picks art itself.
• The images stay public and cacheable. Only the choice is personal. Each image is a normal CDN file shared by every member who gets that choice, so personalization doesn't hurt CDN hit rates.
• Stay consistent within a session. If the same title appears in two rows, show the same art in both, or the member may not recognize it. The client keys artwork by title in its cache, and the server should send the same choice for a session.
• Report what was shown. The learning loop needs to know which art was on screen and whether it led to a play. The client logs an impression with titleId, artworkId, rowId, and position when a card has been at least half visible for about a second.
• Localized art. Title logos are often part of the image and are translated per language, so the artwork choice also depends on the profile's language.

Hover and focus previews

On desktop, resting the mouse on a card makes it grow into a larger card with buttons, and after a moment a muted trailer plays inside it. On TV, the focused title's trailer plays in the big area at the top. Members like it when it works and hate it when it lags or blares, so it needs real design.

The naive version listens for mouseenter, creates a video element, and starts playing. Picture a member moving the mouse from the left of a row to the right to reach the arrow. In under a second the pointer crosses 6 cards.

Each one creates a video, fetches a manifest, starts a decoder, and downloads the first few seconds of video at maybe 1 to 2 MB each. That's around 10 MB of wasted downloads, 6 hardware decoders fighting over a TV that may only have one or two, and a flicker of half-started videos.

One shared preview player

Keep a single preview video element for the whole page, owned by a preview controller, not by cards. When a card reaches the playing stage, the controller moves that element into the card's slot (or positions it over the card) and plays. When another card wins, the same element is reused. This caps decoders at one, avoids the cost of creating media elements, and makes "stop all previews" a single call when a dialog opens or the tab is hidden.

let attempt: { titleId: string; abort: AbortController; timers: number[] } | null = null;

function onIntent(titleId: string) {
  cancel();
  const allowed = previewsAllowed(); // setting, reduced motion, Save-Data
  const abort = new AbortController();
  const expand = window.setTimeout(() => {
    showExpandedCard(titleId);
    if (allowed) prefetchPreview(titleId, abort.signal); // manifest + first segment
  }, 400);
  const timers = [expand];
  if (allowed) {
    timers.push(window.setTimeout(() => {
      playShared(titleId, abort.signal).catch(() => showStill(titleId));
    }, 1400));
  }
  attempt = { titleId, abort, timers };
}

function cancel() {
  if (!attempt) return;
  attempt.timers.forEach((t) => clearTimeout(t));
  attempt.abort.abort(); // stops downloads in flight
  stopShared();
  attempt = null;
}

Autoplay rules and member choice

• Muted by default. Browsers allow muted autoplay without a click, but block autoplay with sound until the user has interacted with the page. video.play() returns a promise that rejects with NotAllowedError when blocked, so always handle it and fall back to the still image.
• A mute toggle on the card sets a session preference: once a member unmutes one preview, later previews keep sound, which is now allowed because they clicked.
• Respect the setting. Netflix lets members turn off autoplay of previews per profile. The flag comes with the profile and previewsAllowed() checks it first.
• Respect prefers-reduced-motion: reduce. Moving video that starts by itself is exactly what that setting asks to avoid. Show the still and a play button instead.
• Respect data saving. If navigator.connection.saveData is true (Chromium only), or the measured bandwidth is very low, skip previews.
• Stop when hidden. On visibilitychange to hidden, or when a modal opens, cancel the attempt.

Prefetching for the real play

A hover is also a strong signal that the member might press play. While the expanded card is open, the client can warm what the real player needs: open a connection to the video CDN with preconnect, fetch the title's playback metadata (manifest URL, resume position, available tracks), and on browsers that allow it, request the DRM license ahead of time. It should not download video segments for the main title; that would be too much waste per hover. The prefetching lesson covers how to judge intent signals like this one.

TV and the remote: spatial navigation

On a TV the member holds a remote with Up, Down, Left, Right, OK, and Back, maybe Play/Pause. There is no pointer to hover and no wheel to scroll. Every key press must move focus to the element the member expects, and the screen must scroll so the focused element is visible. This is called spatial navigation: moving focus by direction on a 2D screen, rather than through a 1D list as Tab does.

The naive answer is to let the platform handle it. Desktop browsers move focus with Tab in document order; arrows scroll the page.

Map Right to "next focusable" and Left to "previous", and Down to... what? In document order, the element after the last card of row 1 is the first card of row 2. So getting from the fourth card of row 1 to the fourth card of row 2 would take 75 presses of Right.

A CSS spatial navigation proposal exists as a draft, but browsers don't ship it, and many TV apps don't run in a normal browser DOM at all. The app has to own focus.

Focus memory between rows

Say focus is on card 5 of "Trending Now" and the member presses Down to "Comedies", which they last left on card 2. There are two sensible rules. Restore: go to the card that row remembers (card 2). Align: go to the card in the same screen column (card 5's column).

Netflix-style TV interfaces usually keep the focused card at a fixed position near the left edge and slide the row under it, which makes both rules land in the same screen spot and keeps the eye still. Our design uses restore with a fixed focus position: each row's remembered index is stored in the same map that holds its page index on the web.

type BrowseFocus = { row: number; colByRow: Map<string, number> };

function move(f: BrowseFocus, key: string, rows: { id: string; length: number }[]) {
  const row = rows[f.row];
  const col = f.colByRow.get(row.id) ?? 0;
  if (key === "ArrowRight") f.colByRow.set(row.id, Math.min(col + 1, row.length - 1));
  if (key === "ArrowLeft") f.colByRow.set(row.id, Math.max(col - 1, 0));
  if (key === "ArrowDown") f.row = Math.min(f.row + 1, rows.length - 1);
  if (key === "ArrowUp") f.row = Math.max(f.row - 1, 0); // past row 0 goes to the hero
  return f; // the renderer scrolls so rows[f.row] and its column are on screen
}

Keys, repeats, and Back

• Holding a key repeats it, often 10 to 30 times a second. If every repeat triggers a row slide animation, the TV falls behind and keeps moving after the member lets go. Apply moves to state immediately, but let the renderer skip to the latest position instead of playing every animation, and drop repeats that arrive while a move is still pending.
• Back is not standard. Each TV platform sends its own key: for example, LG webOS sends key code 461 and Samsung Tizen sends 10009. A small platform layer maps these to one back action.
• Back has a ladder of meanings: close the open dialog; otherwise return focus to the first card of the row; otherwise scroll to the top; otherwise open the menu; only then ask to exit. Members press Back repeatedly to "get out", and each press should do something visible.
• OK on a card opens details; Play on the remote can start the title directly.

The 10-foot UI and TV performance

A TV is viewed from about 3 metres, so text and targets are much larger than on desktop: body text around 24 to 28 pixels on a 1080p layout, few words per card, and a focus state that is obvious from across the room (a scale-up plus a thick, high-contrast outline, not a subtle colour change). Keep important content inside a safe area of about 5 percent from each edge, since some TVs still crop the edges.

TV chips are far slower than laptops, and their browsers or engines are older. Netflix has described running its TV interface on its own rendering layer, called Gibbon, with React on top, rather than a full browser DOM, precisely to control performance on such devices. For an interview, the lessons transfer to any TV stack: keep the rendered tree tiny (fewer cards than desktop), animate only transforms and opacity, keep images in a strict memory budget with a least-recently-used cache, and measure on the slowest device you support.

The title details view

Clicking a card (or pressing OK on TV) opens the title's details: a header with the trailer or hero art, play and add-to-list buttons, the synopsis, cast, maturity rating, a season picker with episodes, and a grid of similar titles. The question is what happens to the browse page underneath.

The naive approach navigates to a new route like /title/80057281, unmounts the browse page, and fetches the details. Closing it navigates back and the browse page mounts again from scratch. The member, who had scrolled 15 rows down and paged three rows sideways, is now at the top. Even if scroll restoration works, every visible image is decoded again and the rows that loaded lazily may load again.

What loads, and when

• Instantly, from the card's data: title, artwork, rating, year, and the match or genre tags the card already had. The dialog opens with these in the same frame as the click, so there's no blank dialog.
• From the hover prefetch: if the member hovered first, the playback metadata and the preview's first segment are already cached, so the header trailer continues instead of restarting. The shared preview element is handed from the card to the dialog header.
• On open: synopsis, cast, and the current season's episodes, in one request of a few KB.
• On demand: other seasons when picked in the season menu, and the similar titles grid when scrolled into view.

For a series, the play button needs to know which episode to play: the episode in progress, or the next one if the last was finished, or episode 1. That decision belongs on the server, which has the full viewing history. The details response carries a playTarget with episode id and start position, so the button label ("Resume S2:E4" or "Play S1:E1") is right on first paint.

Focus and keyboard

Use the native dialog element with showModal(), which makes the rest of the page inert and handles Escape. Move focus to the dialog's heading or Play button when it opens, and return focus to the card that opened it when it closes, even if that card was unmounted and remounted by virtualization in the meantime. Because cards are recreated, store the opener as rowId and titleId, not as a DOM node, and focus the matching card after closing. The focus-management lesson covers the general rules; virtualization is what makes this case tricky.

On TV, the details view is a full screen rather than a dialog, with its own focus tree: buttons in a row, then the season menu, then episodes as a vertical list. Back returns to the browse page with the same row and card focused.

The player: adaptive streaming for long films

The YouTube guide builds the basic pipeline: the video is cut into segments of a few seconds at several qualities, a manifest lists them, and an adaptive bitrate (ABR) rule picks a quality for each segment, and the player uses Media Source Extensions (MSE) to append the segments it chooses into a SourceBuffer that feeds the video element. Read that first. Here we look at what changes for a subscription service that plays protected films and series, mostly on big screens.

• Sessions are long. A member watches a 2-hour film or several episodes in a row. Stable quality over hours matters more than reacting to every small change in bandwidth.
• Screens are big. On a 65-inch TV, the jump from 1080p to 4K is visible, and so is a drop to 480p. Quality switches are noticed.
• Every segment is encrypted. The player needs a license before it can decode the first frame, which adds a step to startup.
• Each title has its own ladder. Netflix described per-title encoding in 2015: a simple cartoon needs far fewer bits than a grainy action film at the same resolution, so each title gets its own set of bitrates. In 2018 it described going further, tuning the encode shot by shot with a framework it calls the dynamic optimizer.

The bitrate ladder

A bitrate ladder is the list of encoded versions of a title, from lowest to highest. The table shows an example ladder for a typical drama. A cartoon's ladder would reach 1080p at maybe half these bitrates, and the player doesn't care: it reads the ladder from the manifest.

Buffer goals for long-form video

The buffer is how many seconds of video are downloaded ahead of the playhead. A bigger buffer survives longer bandwidth drops, but it costs memory, and bytes are wasted if the member stops early. Web players often default to about 30 seconds ahead (hls.js's maxBufferLength is 30), which suits short clips.

For a film, a member who has watched 10 minutes will very likely watch more, so a desktop player can aim for a few minutes ahead once quality is stable. A TV with little memory might stop at 60 seconds. These goals are our example numbers, not Netflix's.

Browsers also cap how much a SourceBuffer can hold and throw a QuotaExceededError when it is full. So the player removes video more than about 30 seconds behind the playhead with SourceBuffer.remove(), and keeps that small window for quick rewinds.

Try the simulator. At 8 Mbps with the 30-second goal, press Play 40 s three times: the player settles on 1080p, and the buffer stops near 30 seconds. Now drag the bandwidth down to 0.5 Mbps and press Next segment. The player still believes the old estimate and picks a 1080p segment, which takes 40 seconds to download: longer than the buffer, so playback freezes.

Reset, choose the 120-second goal, and repeat the same presses. The buffer is now past 50 seconds, so the same slow segment only shrinks it, and the player steps down before anything shows. A long buffer turns network trouble into a quality dip instead of a spinner. (Real players also abandon a download that is clearly too slow and refetch it at a lower rung; the YouTube guide covers that.)

Stable quality over fast reactions

• Switch up slowly, switch down fast. Step up one rung only after throughput has stayed above the next rung with a margin (say 1.4 times its bitrate) for 10 to 20 seconds. Step down as soon as the buffer is falling and the estimate is below the current rung.
• Let the buffer decide when it's healthy. Above 60 seconds of buffer, a short dip doesn't matter, so ignore it. Buffer-based rules, studied in a 2014 paper with Netflix experiments, select quality mainly from buffer level for this reason.
• Never exceed the screen. Cap the rung at the player's size times devicePixelRatio, and at what the DRM level allows (next chapter).
• Pick a codec once. Ask navigator.mediaCapabilities.decodingInfo(), including a keySystemConfiguration for encrypted content, whether AV1, HEVC, VP9, or H.264 will be smooth and power efficient here, and stay with that codec for the session.

Startup time: what happens after Play

Between pressing Play and the first frame, the player must get playback metadata (manifest URL, tracks, resume position), the manifest itself, a DRM license, the init segment, and the first media segment, then decode. Done one after another, with 100 ms round trips, new connections to each server, and no hover prefetch, that's easily 2 to 3 seconds.

Done well, it's under 1 second: the metadata was prefetched on hover, the license request runs in parallel with segment downloads, the first segment comes from a low rung (rung 2 or 3, about 400 to 750 KB) starting at the resume position, and the player begins as soon as one segment is buffered.

DRM, subtitles, and audio tracks

Studios license films on the condition that they're protected. DRM (digital rights management) means the segments on the CDN are encrypted, and only a trusted piece of software in the browser or device, called the CDM (content decryption module), can get the keys and decrypt them. The page's JavaScript never sees the keys or the decrypted frames. The web API that connects the page to the CDM is Encrypted Media Extensions (EME), a W3C standard supported by all major browsers.

Three DRM systems cover nearly every device. Each browser ships with one or more of them, and the player must ask which are available, in order of preference.

The systems also differ in how well they protect the content. A CDM that decrypts and decodes in secure hardware is trusted more than one that runs in software. Studios typically allow the highest resolutions only with hardware-backed protection, which is why streaming services publish different maximum qualities per browser and operating system.

Netflix's help pages list such limits per browser. The player reads the allowed maximum from the license or the playback metadata and caps its ladder to it.

The EME flow, step by step

const config = [{
  initDataTypes: ["cenc"],
  videoCapabilities: [{ contentType: 'video/mp4; codecs="avc1.640028"', robustness: "HW_SECURE_ALL", encryptionScheme: "cbcs" }],
}];
const access = await navigator.requestMediaKeySystemAccess("com.widevine.alpha", config);
const mediaKeys = await access.createMediaKeys();
await video.setMediaKeys(mediaKeys);

const session = mediaKeys.createSession();
session.addEventListener("message", async (event) => {
  const res = await fetch(licenseUrl, {
    method: "POST",
    body: event.message, // opaque challenge from the CDM
    headers: { Authorization: `Bearer ${playbackToken}` },
  });
  if (!res.ok) return showLicenseError(res.status, await res.json()); // e.g. STREAM_LIMIT_REACHED
  await session.update(await res.arrayBuffer()); // keys go into the CDM
});
await session.generateRequest("cenc", psshFromManifest); // PSSH: the DRM's init data, from the manifest

In practice you try configs in order (hardware robustness first, then software; Widevine, then PlayReady) and keep the first that resolves. Player libraries such as Shaka Player wrap this flow, but you should be able to explain it. The license request is the step where business rules live: the server checks the member's plan, the region's rights for this title, and the number of streams already playing on the account. A refusal must become a clear message, not a black screen.

The player as a state machine

Add DRM to loading, buffering, seeking, and errors, and a pile of booleans like isLoading, hasLicense, isStalled soon allows impossible combinations. Model the player as one explicit state machine instead: each state lists which events it accepts, and the UI renders from the state alone. The state-machines lesson covers the technique.

Subtitles and captions

Netflix offers subtitles and closed captions (subtitles plus sound descriptions such as "[door creaks]") in many languages. They are fetched as separate timed-text files, in timed-text formats such as WebVTT or TTML/IMSC (each cue is text with a start and end time), only for the language the member picks.

The player can hand them to the browser as a track element, but many services render them in their own overlay above the video, for three reasons: the same look on every device, member styling (size, colour, background) that applies everywhere, and moving captions up when the controls appear so they're never covered. The overlay updates on the video's timeupdate or, more precisely, from a requestVideoFrameCallback loop where supported.

Audio languages and audio description

Audio is its own stream, separate from video, so the same video segments serve every language. The manifest lists audio tracks by language and kind: original, dubbed, and audio description (narration of what's on screen for blind and low-vision members). Switching language mid-play means the player clears the audio SourceBuffer ahead of the playhead and fetches the new track from the current time, a short pause at most. The profile remembers the chosen audio and subtitle languages per title and as a default, so the next episode starts with the same choices.

Resume, Continue Watching, skip intro, and the next episode

A member stops an episode on the living room TV at 31:40, then opens Netflix on a laptop in bed. The Continue Watching row should show that episode first with its progress bar at about 60 percent, and Resume should start at 31:40, or a few seconds before. This one feature touches the player, the browse page, the API, and caching.

The naive approach saves the position when the member presses Stop or closes the player. But members rarely press Stop. They turn off the TV, close the laptop lid, or lose the connection, and the save never runs. The next device then resumes from where the previous session started.

Rules that make resume feel right

• Each save carries a timestamp and a session id. The server keeps, per profile and title, the save with the latest timestamp. If two devices play the same episode at once, the most recent activity wins.
• Rewind a little on resume. Starting 3 to 5 seconds before the saved point helps the member remember where they were.
• Finished means near the end, not at the end. Once the credits start (a marker in the metadata), or past about 95 percent, the title counts as watched. For a series, the play target moves to the next episode, which is what Continue Watching should show.
• Fresh row on return. When the member comes back to the browse page after playing, update the Continue Watching row in the local cache from the last save straight away, then refetch it. Don't wait for a full browse refresh.
• Fresh row on another device. The Continue Watching row has a short cache lifetime (seconds to a minute), unlike other rows that can be cached for much longer, because it changes whenever any device in the household plays something.

Skip intro and skip recap

The playback metadata includes time markers per episode: intro start and end, recap start and end, and credits start. The player compares the current time to these ranges on each timeupdate and shows a Skip Intro button inside the intro range. On TV, the button takes focus when it appears, so a single OK press skips; when the intro ends, focus returns to nothing and the controls hide.

Skipping is a seek to the intro's end, and the player can prefetch the segment at that point when the intro begins, so the skip lands on video that's already buffered.

The next episode countdown

When the credits marker is reached, the player shrinks the video into a corner and shows the next episode with a countdown of a few seconds. Pressing Next or letting the countdown end plays it; any other input cancels the countdown and lets the credits play.

Starting the next episode fast is easy if the player has already prepared it during the credits: fetch its playback metadata and license, and buffer its first segment at a low rung. After a number of episodes with no input at all, Netflix asks "Are you still watching?" before continuing, which saves bandwidth for members who fell asleep.

Profiles and kids mode

One account, up to 5 profiles, all sharing devices. Each profile has its own rows, history, Continue Watching, My List, language, subtitle style, preview setting, and maturity limit. A kids profile shows only titles rated for children and a simpler, brighter interface. A profile can have a 4-digit lock so children can't open a parent's profile.

The frontend risk is leaking one profile's data into another. Imagine the client caches the browse response under the key browse. A parent switches from their profile to the kids profile, and for a moment, until the refetch lands, the kids profile shows the parent's rows, artwork and all. On a kids profile, that's a serious bug, not a cosmetic one.

Scope everything by profile

• Cache keys include the profile id: ['browse', profileId], ['title', titleId, profileId]. A switch can never read the other profile's entry.
• Switching clears and aborts. On switch, abort every request in flight, stop the preview, drop the in-memory cache for the old profile, and reset the browse store (row pages, focus memory). Show the profile's loading screen, not the old content.
• The server enforces maturity. The client never filters titles by rating itself; it only shows what the API returns for that profile. Client-side filtering would mean a kids profile downloads adult titles and artwork and merely hides them.
• The lock is checked on the server. The PIN is sent to an API that returns a profile session. A PIN check in JavaScript would be trivial to bypass.
• Other tabs follow. The selected profile is part of the session cookie, so a switch in one tab affects the next request in every tab. Post a message on a BroadcastChannel so other open tabs reload into the new profile instead of mixing two profiles' data.

Kids mode is a theme and a ruleset, not a second app

The kids interface looks different: bigger artwork, characters as row headers, no mature artwork, no search results outside kids titles. It's tempting to build it as a separate app.

It's cheaper to keep one browse page and one player, with the profile's type choosing a theme (design tokens for colours, sizes, and fonts) and a set of feature flags (for example, previews off by default, no title ratings shown). The data rules stay on the server. The feature-flags lesson covers how to keep such flags manageable.

Architecture: the pieces and their boundaries

With the hard parts decided, we can draw the client. The guiding idea is that the fast-changing machinery (the player's segment loop, the focus engine's key handling, the preview timers) lives in plain TypeScript modules outside the React tree. React components subscribe to the few facts they display. A segment append every 4 seconds or a key repeat 20 times a second should never re-render the browse page.

What the client talks to

• A backend-for-frontend (BFF) for all page data: browse rows, details, playback metadata, profile settings, writes like My List and ratings. It shapes responses per device type, so the TV gets fewer, exact-size artwork URLs and the web gets srcset variants. Netflix's apps long fetched data through Falcor, its own JSON Graph library, and Netflix has since written about moving to a federated GraphQL API (from 2020) and migrating its mobile apps off Falcor. A GraphQL gateway or a REST BFF both fit this role.
• An image CDN that serves artwork in several widths and formats.
• A video CDN that serves manifests and segments. Netflix runs its own, called Open Connect, with servers placed inside internet providers' networks so video travels a short distance.
• A license server for DRM, which the player calls through the BFF or directly with a short-lived playback token.

Why split it this way? The BFF exists because the browse page needs data from many services (ranking, artwork choice, viewing history, ratings) and a TV can't afford a dozen round trips. The license server stays separate because its rules and keys are security-critical and change on their own schedule. Video bytes never touch the BFF: they come straight from the CDN, because that's where the scale is.

The data flow figure follows one browse visit: the shell requests the first chunk of rows, the response fills the query cache, rows render from the cache, cards request artwork from the image CDN, and writes such as adding to My List go back through the BFF with an optimistic update. The player has its own lane: metadata from the BFF, manifest and segments from the video CDN, the license from the license server, and heartbeats back to the BFF.

Data model: what lives where

The client holds four kinds of data, and each kind has a natural home. Server data that many screens share (titles, rows) goes in a normalized query cache. UI positions that must survive unmounting (row pages, focus) go in a small browse store mirrored to history.state.

Things that should be shareable go in the URL. Player state lives in the player controller. Very little needs to persist on the device.

Normalization matters here because one title shows up in many places: in Trending Now, in Because You Watched X, in Continue Watching, in the details dialog, and in My List. If each row carried its own full copy, adding the title to My List would need updating five copies. Instead, rows hold title ids, and titles are stored once by id. A row is a list of ids plus a cursor for the next page.

type Title = {
  id: string;
  name: string;
  kind: "movie" | "series";
  maturity: string;          // "TV-14", shown, never filtered on the client
  artwork: { artworkId: string; placeholderColor: string; srcset: string };
  previewManifestUrl?: string;
};

type Row = {
  id: string;
  label: string;             // "Because you watched Dark"
  kind: "standard" | "continue-watching" | "top-10";
  titleIds: string[];        // loaded so far
  nextCursor: string | null; // more titles in this row
};

type TitleProgress = { titleId: string; episodeId?: string; positionSec: number; durationSec: number; updatedAt: number };

type BrowseUiState = { pageByRow: Record<string, number>; focus: { row: number; colByRow: Record<string, number> }; scrollY: number };

Notice what isn't stored on the device: viewing history, My List, and resume positions all live on the server, because they must follow the profile across devices. The device keeps only facts about itself, like how fast its network was last time.

Interface: the API the client needs

The client needs five groups of calls: browse rows, title details, playback metadata, the license, and writes (progress, My List, ratings). Shape them around screens, not around backend services, and paginate in two directions: rows down the page, and titles within a row.

GET /api/browse?rows=8&perRow=12&cursor= HTTP/1.1
Cookie: session=...; profile=p_42
Accept: application/json

200 OK
Cache-Control: private, max-age=300
{
  "hero": { "titleId": "t_81", "previewManifestUrl": "https://..." },
  "rows": [
    { "id": "r_cw", "label": "Continue Watching", "kind": "continue-watching",
      "titleIds": ["t_12", "t_90"], "nextCursor": null, "maxAgeSec": 30 },
    { "id": "r_trend", "label": "Trending Now", "kind": "standard",
      "titleIds": ["t_81", "t_7", "..."], "nextCursor": "c_row_12" }
  ],
  "titles": { "t_81": { "name": "...", "artwork": { "artworkId": "a_3", "...": "..." } } },
  "nextRowsCursor": "c_page_8"
}

• GET /api/browse?cursor=c_page_8&rows=6: the next chunk of rows, fetched when the sentinel nears.
• GET /api/rows/r_trend/titles?cursor=c_row_12&count=12: more titles in one row, fetched when the member nears the last loaded page.
• GET /api/titles/t_81: details, with playTarget (episode and start position) and the current season's episodes.
• GET /api/playback/t_81?episode=e_4: manifest URLs per format, audio and text tracks, markers (intro, recap, credits), the allowed maximum quality, and a short-lived playback token for the license server.
• POST /api/license with the CDM's challenge bytes and the playback token: returns the license bytes, or a typed error.
• POST /api/progress: { titleId, episodeId, positionSec, sessionId, sentAt, quality } from heartbeats and event saves; returns 204.
• PUT /api/my-list/t_81 and DELETE /api/my-list/t_81: optimistic on the client, rolled back on failure.

Errors the member can understand

Most errors on the browse page can be hidden: a row that fails is retried and then dropped. Playback errors can't, so the API returns a typed error with a code the client maps to a clear message and an action. The playback-related ones are the important set.

{
  "error": {
    "code": "STREAM_LIMIT_REACHED",
    "message": "Too many people are using this account right now.",
    "retryable": false,
    "details": { "activeStreams": 2, "planLimit": 2 }
  }
}

Other codes in the same family: NOT_AVAILABLE_IN_REGION, PROFILE_MATURITY_BLOCKED, DEVICE_NOT_SUPPORTED (the CDM can't meet the title's protection rules), and PLAYBACK_TOKEN_EXPIRED, which is retryable: the client fetches fresh playback metadata and tries again without bothering the member.

Performance: the landing page and the browse page

There are two very different first loads. The logged-out landing page is a marketing page: the same for everyone in a country and language, read by search engines, and its job is to get a visitor to sign up. The browse page is private, personal, and heavy with images. They deserve different rendering strategies.

Core Web Vitals targets with real causes

Splitting the code by intent

The browse page doesn't need the player. The player bundle (ABR, MSE adapter, EME manager, timed-text renderer) can be 100 KB or more compressed, so it is its own chunk. Load it on intent: when a card is expanded or the details dialog opens, import() the player chunk in the background. By the time the member presses Play, the code is ready.

The details dialog and the search page are split the same way. The core-web-vitals lesson covers measuring these in the field.

Budgets on TV

• Rendered cards: keep the window small, about 5 rows of 10 cards on screen and nearby, since every card is a texture in memory.
• Image memory: an LRU cache of decoded artwork with a byte budget, evicting cards far from focus.
• Animation: only transforms and opacity; no shadows or blurs that need repainting on each frame.
• Startup: the app launches into the profile picker from a cached bundle; browse data loads while the member picks.

Accessibility: rows, previews, captions

Netflix's audience includes blind members who use screen readers, deaf members who rely on captions, members who can't use a mouse, and members who get motion sickness from moving video. The browse page and previews are where accessibility goes wrong most often, because they are built for a pointer.

Start with keyboard users on the web. If every card is a link and a tab stop, reaching the tenth row means pressing Tab dozens of times per row, and virtualization makes it worse: the cards a member could tab to keep changing. The page needs a structure that's fast to move through and that tells a screen reader where it is.

Telling a screen reader about cards it can't see

• Each card's list item carries aria-setsize with the row's total and aria-posinset with its position, so "Stranger Things, 4 of 75" is announced even though only 18 cards exist in the DOM.
• A card's accessible name includes what a sighted member sees at a glance: the title, and the progress if any ("Dark, 40 minutes left"). Art is decorative in that context, so its alt is empty.
• The paging arrows are real buttons with labels like "Show more titles in Trending Now", and they move focus to the first new card.
• Keyboard focus on a card opens the same expanded card as hover, with its Play, My List, and More info buttons reachable by Tab.

Previews that respect members

Auto-playing video is a problem for people with vestibular disorders and for screen reader users, whose speech competes with the trailer's sound. The previews chapter already starts them muted, lets members turn them off, and shows the still artwork when prefers-reduced-motion: reduce matches. One more rule: any preview that plays must have a visible pause control. WCAG's Pause, Stop, Hide criterion (2.2.2) requires one for moving content that starts by itself and lasts more than 5 seconds.

Captions and the player

• Every title has captions; the profile remembers the language and whether they're on.
• Members can style captions: size, font, colour, background, and edge. The custom renderer applies these everywhere.
• Audio description tracks appear in the audio menu with a clear label.
• All controls are buttons with names and states (aria-pressed for subtitles on), reachable by Tab, with shortcuts such as Space for play and pause and F for fullscreen.
• Status changes ("Subtitles: English", "Skipped intro") are announced through one polite live region, not on every time update.

On TV, platform screen readers read what the app exposes through the platform's accessibility API. The focus engine must report every focus change to it, with the same names the web uses: row label, title, position in the row.

Observability: knowing playback is good

How would you know that a release made playback worse? Not from error logs alone: a player that stalls for 3 seconds every 10 minutes throws no errors, and members just get annoyed. Playback quality must be measured from real sessions, on real devices and networks, and broken down finely enough to find the cause. The real-user-monitoring lesson covers the general pipeline; here are the metrics specific to streaming.

Be careful what counts as a stall. When a member seeks, the player waits for data at the new position: that wait is expected and belongs to a separate seek latency metric. Only waits that interrupt normal playback count as rebuffering. Mixing the two would make a change that improves seeking look like it worsened smoothness.

let watchedMs = 0, stalledMs = 0, stalls = 0, since = performance.now();
let current: PlayerState = "loading";

player.onStateChange((next) => {
  const now = performance.now();
  if (current === "playing") watchedMs += now - since;
  if (current === "rebuffering") stalledMs += now - since;
  if (next === "rebuffering" && current === "playing") stalls++; // not after "seeking"
  current = next;
  since = now;
});

function heartbeatPayload() {
  return { watchedMs, stalledMs, stalls, ratio: stalledMs / Math.max(1, watchedMs + stalledMs) };
}

Using the metrics to ship changes

Changes to the ABR rules, buffer goals, or preview delays should ship as A/B tests behind feature flags, with these metrics as guardrails: a new ABR rule that raises average bitrate by 5 percent but also raises the rebuffer ratio from 0.4 to 0.6 percent is a loss. Netflix is well known for testing nearly every product change this way. The ab-testing and feature-flags lessons cover the mechanics; the frontend's part is to send clean, comparable metrics with the experiment group attached.

Running it in the interview

You can't cover all of this in 45 minutes, and you shouldn't try. The goal is to show you can find the hard parts, make clear decisions with numbers, and go deep on two or three of them. Here's one way to spend the time.

Say the numbers out loud. "3,000 cards would be 45,000 nodes, so I'll window both directions and render about 150" is much stronger than "I'll virtualize". "A 1280 by 720 image decodes to 3.7 MB, so on a TV we size art to the card" shows you know where the cost actually is. And name what you are not doing and why, like offline downloads being app-only.

Follow-up questions to expect