Video Player

The Problem

Design a video player: a play button, a progress bar, volume, quality selection, captions, fullscreen. The video is delivered by adaptive streaming so it works on a poor connection as well as a good one.

Two things make this a system design problem rather than a component exercise. First, the player is a control loop - it continuously measures throughput and buffer level and makes a fetch decision every few seconds, and the quality of that loop is the quality of the product. Second, the browser gives you a real engine but very little of the surface, so a custom control bar means re-implementing everything the native controls provided, including the accessibility they had for free.

Requirements

Functional

• Adaptive quality selection, automatic by default with a manual override.
• Play, pause, seek, volume, mute, playback speed.
• Captions with user control over visibility.
• Fullscreen and picture-in-picture.
• Resume from the viewer's last position.
• Keyboard shortcuts matching platform conventions.

Non-functional

• Time to first frame under two seconds on a typical connection.
• Stalls rare, and recovered from without user action.
• Analytics collection never causes a dropped frame.
• Fully keyboard operable and screen reader accessible.

Adaptive Bitrate Streaming

The video is not one file. It is encoded several times at different bitrates and resolutions, each cut into segments of a few seconds, described by a manifest.

master.m3u8                     ← lists the renditions
├── 1080p/index.m3u8            ← 5 Mbps  → seg-0.ts, seg-1.ts, …
├── 720p/index.m3u8             ← 2.8 Mbps
├── 480p/index.m3u8             ← 1.2 Mbps
└── 240p/index.m3u8             ← 400 Kbps

Because the player fetches one segment at a time, it can choose a different rendition for every segment. That is the entire mechanism behind quality adapting mid-playback.

Two formats dominate. HLS (.m3u8, Apple) is universal, and is natively supported in Safari - where you can hand the manifest URL straight to a <video> element. DASH (.mpd) is the open standard, more flexible, and requires a JavaScript player everywhere. In practice most products ship HLS and use hls.js on browsers without native support, which works by feeding segments into Media Source Extensions - the API that lets JavaScript supply media data to a video element rather than pointing it at a URL.

Diagram
100%
flowchart TB
    subgraph NET["Network"]
        MAN["master.m3u8<br/>rendition list"]
        SEG["segment URLs<br/>seg-N.ts per rendition"]
    end

    subgraph PLAYER["Player - the control loop"]
        PARSE["parse manifest -><br/>available renditions"]
        ABR{"ABR controller<br/>every segment:<br/>throughput + buffer level<br/>-> which rendition?"}
        FETCH["fetch next segment<br/>at the chosen rendition"]
        THRU["throughput estimator<br/>bytes / seconds,<br/>EWMA over recent segments"]
    end

    subgraph MSE["Media pipeline (browser)"]
        SB["SourceBuffer<br/>appendBuffer(segment)"]
        BUF[("buffered ranges<br/>target 20-30s VOD<br/>2-6s live")]
        DEC["decoder<br/>(hardware where available)"]
        REN["compositor -> screen"]
    end

    MAN --> PARSE --> ABR
    ABR --> FETCH --> SEG
    SEG --> THRU --> ABR
    SEG --> SB --> BUF --> DEC --> REN
    BUF -->|"buffer level feeds<br/>the next decision"| ABR

    STALL{"buffer < 1s?"}
    BUF --> STALL
    STALL -->|"yes"| DOWN["step down aggressively,<br/>fire 'waiting', show spinner"]
    STALL -->|"no, and stable > 10s"| UP["step up one rendition<br/>(never jump to the top)"]
    DOWN --> ABR
    UP --> ABR

    style PLAYER fill:#1e3a5f,stroke:#3b82f6
    style MSE fill:#1e3f2d,stroke:#22c55e
    style DOWN fill:#3f1e1e,stroke:#ef4444
    style UP fill:#3f2d1e,stroke:#f59e0b
Zoom or open fullscreen for a closer look
visualized by

The decision itself is a small piece of arithmetic with important safety margins:

type Rendition = { id: string; bitrateBps: number; width: number; height: number };

const SAFETY_FACTOR = 0.8;      // never assume the full measured bandwidth
const PANIC_BUFFER_S = 2;       // below this, drop hard
const COMFORT_BUFFER_S = 12;    // above this, consider stepping up

class BitrateSelector {
  /** Exponentially weighted moving average of measured throughput. */
  private estimateBps = 1_000_000;

  constructor(private renditions: Rendition[]) {
    // Ascending, so index 0 is the safest choice.
    this.renditions = [...renditions].sort((a, b) => a.bitrateBps - b.bitrateBps);
  }

  recordSegment(bytes: number, durationMs: number) {
    const sampleBps = (bytes * 8) / (durationMs / 1000);
    // Weight recent samples heavily: a network change matters more than history.
    this.estimateBps = 0.7 * sampleBps + 0.3 * this.estimateBps;
  }

  select(currentId: string, bufferedAheadS: number, viewportWidth: number): Rendition {
    const currentIndex = this.renditions.findIndex((r) => r.id === currentId);

    // Buffer is about to run dry. Stalling is far worse than looking soft, so
    // drop to the lowest rendition immediately rather than stepping down.
    if (bufferedAheadS < PANIC_BUFFER_S) return this.renditions[0];

    const affordable = this.renditions.filter(
      (rendition) =>
        rendition.bitrateBps <= this.estimateBps * SAFETY_FACTOR &&
        // No point fetching 1080p into a 640px-wide player.
        rendition.width <= viewportWidth * window.devicePixelRatio * 1.2,
    );

    const best = affordable[affordable.length - 1] ?? this.renditions[0];
    const bestIndex = this.renditions.indexOf(best);

    // Step up by one, and only with buffer in hand. Jumping straight to the
    // top rendition on one fast segment is how oscillation starts.
    if (bestIndex > currentIndex) {
      if (bufferedAheadS < COMFORT_BUFFER_S) return this.renditions[currentIndex];
      return this.renditions[Math.min(currentIndex + 1, bestIndex)];
    }

    return best;
  }
}

Five decisions in that code, each corresponding to a viewer-visible failure:

1. Throughput is measured from actual segment downloads, not a speed test. A speed test measures a moment; segments measure the conditions you are actually operating in.
2. An 80% safety factor, because a rendition that cannot be sustained causes a stall - and a stall costs far more viewer goodwill than a lower resolution.
3. Buffer level overrides throughput below the panic threshold. A player with two seconds buffered must drop hard regardless of how good the last measurement looked.
4. Step up one rendition at a time, only with comfortable buffer. Otherwise a single fast segment triggers a jump to the top, which immediately fails and drops back - the oscillation that makes quality visibly flicker.
5. Cap by rendered size. Fetching 1080p into a 640px player wastes bandwidth for no visible gain, and on a phone it also wastes decode power and battery.

Startup deserves a special case, because at that moment there is no measurement to work from. Starting at a low rendition gets a picture on screen fast and steps up within a few seconds; starting high risks a long blank period on a slow connection. Most players start low or store the previous session's estimate and start from that.

Buffer Management

Buffer is insurance against network variability, and it is paid for in startup latency and wasted bandwidth.

The resolution is asymmetric: a small buffer to start, growing once playback is stable.

const STARTUP_BUFFER_S = 3;
const STEADY_BUFFER_S = 25;
const LIVE_BUFFER_S = 6;

function targetBuffer(state: PlayerState): number {
  if (state.isLive) return LIVE_BUFFER_S; // more buffer = further behind live
  if (!state.hasStartedPlayback) return STARTUP_BUFFER_S;
  return STEADY_BUFFER_S;
}

function bufferedAhead(video: HTMLVideoElement): number {
  const { buffered, currentTime } = video;

  for (let index = 0; index < buffered.length; index += 1) {
    // Ranges are disjoint - seeking creates gaps - so find the one containing
    // the playhead rather than assuming there is only one.
    if (buffered.start(index) <= currentTime && currentTime <= buffered.end(index)) {
      return buffered.end(index) - currentTime;
    }
  }

  return 0;
}

video.buffered is a TimeRanges object with multiple disjoint ranges, because seeking creates gaps. Code that reads buffered.end(0) and calls it the buffer level is wrong after any seek, and the resulting misreading makes the ABR controller behave erratically in exactly the sessions where viewers are most active.

Two related concerns. Live streams invert the priority: buffer means latency behind the live edge, so live players run short buffers and accept more stalls. And preload is a real cost decision - preload="auto" on a page with several videos starts downloading all of them, which is a bandwidth bill and a main-thread cost for content nobody may watch. preload="metadata" is the sane default, giving you duration and dimensions without segments.

Custom Controls on the HTMLVideoElement API

The <video> element is the engine. Custom controls are a presentation layer over its API.

type PlayerCommands = {
  play: () => Promise<void>;
  pause: () => void;
  seek: (seconds: number) => void;
  setVolume: (level: number) => void;
  toggleMute: () => void;
  setPlaybackRate: (rate: number) => void;
};

function createCommands(video: HTMLVideoElement): PlayerCommands {
  return {
    // play() returns a promise that rejects when autoplay policy blocks it.
    // An unhandled rejection here is a console error on every page load.
    play: async () => {
      try {
        await video.play();
      } catch (error) {
        if (error instanceof DOMException && error.name === 'NotAllowedError') {
          // Autoplay blocked - the correct response is to mute and retry, or
          // show a play button, not to report an error to the user.
          video.muted = true;
          await video.play().catch(() => undefined);
          return;
        }
        throw error;
      }
    },
    pause: () => video.pause(),
    // Clamp: assigning a currentTime beyond duration throws in some browsers.
    seek: (seconds) => {
      video.currentTime = Math.max(0, Math.min(seconds, video.duration || 0));
    },
    setVolume: (level) => {
      video.volume = Math.max(0, Math.min(1, level));
      if (level > 0) video.muted = false;
    },
    toggleMute: () => {
      video.muted = !video.muted;
    },
    setPlaybackRate: (rate) => {
      video.playbackRate = rate;
    },
  };
}

The state to render comes from media events, and reading it correctly matters:

type PlayerState = {
  status: 'idle' | 'loading' | 'playing' | 'paused' | 'buffering' | 'ended' | 'error';
  currentTime: number;
  duration: number;
  bufferedAheadS: number;
  volume: number;
  isMuted: boolean;
  isSeeking: boolean;
};

function subscribe(video: HTMLVideoElement, onChange: (patch: Partial<PlayerState>) => void) {
  const handlers: Record<string, () => void> = {
    loadedmetadata: () => onChange({ duration: video.duration, status: 'paused' }),
    play: () => onChange({ status: 'playing' }),
    pause: () => onChange({ status: 'paused' }),
    // 'waiting' is the buffering signal; 'stalled' is unreliable across browsers.
    waiting: () => onChange({ status: 'buffering' }),
    playing: () => onChange({ status: 'playing' }),
    seeking: () => onChange({ isSeeking: true }),
    seeked: () => onChange({ isSeeking: false }),
    ended: () => onChange({ status: 'ended' }),
    error: () => onChange({ status: 'error' }),
    // Fires 4-66 times a second. Keep this handler trivial.
    timeupdate: () => onChange({ currentTime: video.currentTime }),
    progress: () => onChange({ bufferedAheadS: bufferedAhead(video) }),
    volumechange: () => onChange({ volume: video.volume, isMuted: video.muted }),
  };

  for (const [event, handler] of Object.entries(handlers)) {
    video.addEventListener(event, handler);
  }

  return () => {
    for (const [event, handler] of Object.entries(handlers)) {
      video.removeEventListener(event, handler);
    }
  };
}

Diagram
100%
stateDiagram-v2
    [*] --> Idle

    Idle --> Loading: src set / load()
    Loading --> Ready: loadedmetadata
    Loading --> Error: error (network, decode, unsupported)

    Ready --> Playing: play() resolves
    Ready --> Blocked: play() rejects (autoplay policy)
    Blocked --> Playing: muted retry, or user gesture

    Playing --> Buffering: 'waiting' (buffer ran dry)
    Buffering --> Playing: 'playing' (buffer recovered)
    Buffering --> Error: repeated failures exhaust retries

    Playing --> Paused: pause()
    Paused --> Playing: play()

    Playing --> Seeking: currentTime assigned
    Paused --> Seeking: currentTime assigned
    Seeking --> Playing: 'seeked' and was playing
    Seeking --> Paused: 'seeked' and was paused

    Playing --> Ended: 'ended'
    Ended --> Playing: replay (seek to 0 + play)

    Error --> Loading: retry with backoff

    note right of Buffering
        Do not show a spinner
        immediately - a sub-300ms
        rebuffer is invisible, and a
        flashing spinner reads as
        instability that is not there.
    end note

    note right of Blocked
        Autoplay policy is a normal
        outcome, not a failure.
        Mute and retry, or show
        a play affordance.
    end note
Zoom or open fullscreen for a closer look
visualized by

Three details this state machine captures that naive players miss. waiting is the buffering signal, not stalled, which fires inconsistently. The spinner is delayed by ~300ms, because a brief rebuffer is imperceptible and a flashing spinner suggests instability the viewer would not otherwise have noticed. And autoplay rejection is a state, not an error - it happens on most page loads by policy, and the right response is to mute and retry rather than surface a failure.

Keyboard, Captions and Accessibility

Custom controls mean re-implementing what the native ones provided, and this is the part most often skipped.

<div
  role='region'
  aria-label='Video player'
  onKeyDown={onKeyDown}
  tabIndex={-1}>
  <video ref={videoRef} playsInline poster={posterUrl}>
    {/* A real text track: the browser renders and positions the cues, and the
        track is exposed to assistive technology. */}
    <track
      kind='captions'
      src='/captions/en.vtt'
      srcLang='en'
      label='English'
      default
    />
    <track kind='descriptions' src='/descriptions/en.vtt' srcLang='en' label='Audio descriptions' />
  </video>

  <button
    type='button'
    aria-label={status === 'playing' ? 'Pause' : 'Play'}
    aria-keyshortcuts='k Space'
    onClick={togglePlay}>
    {status === 'playing' ? <Pause aria-hidden /> : <Play aria-hidden />}
  </button>

  {/* The progress bar is a slider over time, and its value must be readable. */}
  <div
    role='slider'
    tabIndex={0}
    aria-label='Seek'
    aria-valuemin={0}
    aria-valuemax={Math.floor(duration)}
    aria-valuenow={Math.floor(currentTime)}
    aria-valuetext={`${formatDuration(currentTime)} of ${formatDuration(duration)}`}
    onKeyDown={onSeekKeyDown}
  />

  {/* Announce state changes for viewers not watching the control bar. */}
  <div role='status' aria-live='polite' className='sr-only'>
    {announcement}
  </div>
</div>

const SEEK_STEP_S = 5;
const VOLUME_STEP = 0.1;

function onKeyDown(event: React.KeyboardEvent) {
  // Do not hijack keys while the viewer is typing in a comment box.
  if (isTypingTarget(event.target)) return;

  switch (event.key) {
    case ' ':
    case 'k':
      event.preventDefault(); // Space would scroll the page
      togglePlay();
      announce(status === 'playing' ? 'Paused' : 'Playing');
      break;
    case 'ArrowLeft':
    case 'j':
      event.preventDefault();
      commands.seek(video.currentTime - SEEK_STEP_S);
      break;
    case 'ArrowRight':
    case 'l':
      event.preventDefault();
      commands.seek(video.currentTime + SEEK_STEP_S);
      break;
    case 'ArrowUp':
      event.preventDefault();
      commands.setVolume(video.volume + VOLUME_STEP);
      break;
    case 'ArrowDown':
      event.preventDefault();
      commands.setVolume(video.volume - VOLUME_STEP);
      break;
    case 'm':
      commands.toggleMute();
      announce(video.muted ? 'Muted' : 'Unmuted');
      break;
    case 'f':
      void toggleFullscreen();
      break;
    case 'c':
      toggleCaptions();
      announce(captionsEnabled ? 'Captions off' : 'Captions on');
      break;
    default:
      // 0-9 jump to that decile, matching the platform convention.
      if (/^[0-9]$/.test(event.key)) {
        commands.seek((Number(event.key) / 10) * video.duration);
      }
  }
}

Five obligations:

• Captions through <track>, not burned into the video or rendered as a custom overlay. The browser positions cues correctly, respects the user's caption styling preferences, and exposes the track to assistive technology. Manifest-provided subtitle renditions are the equivalent for adaptive streams.
• The progress bar is a slider with aria-valuetext. aria-valuenow={91} is announced as "91"; aria-valuetext="1:31 of 4:12" is announced as something a person can use.
• Conventional shortcuts. Space, arrows, f, m, c, digits. Viewers arrive with expectations set by other players, and matching them is free.
• State changes announced through a polite live region, so a screen reader user learns that playback started without inspecting the button.
• Autoplay is muted and stoppable. Unexpected audio is an accessibility failure as well as an annoyance, and browsers block it anyway.

The playsInline attribute deserves a mention: without it, iOS Safari takes video fullscreen on play, which destroys any inline layout. It is one attribute and a very common bug.

The general reasoning about media accessibility, focus management across fullscreen transitions and shortcut discoverability is in Accessibility Architecture.

Fullscreen and Picture-in-Picture

async function toggleFullscreen(container: HTMLElement) {
  if (document.fullscreenElement) {
    await document.exitFullscreen();
    return;
  }

  // Request on the CONTAINER, not the video element: fullscreening the video
  // itself hands control back to the browser's native UI and hides yours.
  await container.requestFullscreen({ navigationUI: 'hide' });

  // Best-effort, and unsupported on desktop - hence the swallowed rejection.
  await screen.orientation?.lock('landscape').catch(() => undefined);
}

async function togglePictureInPicture(video: HTMLVideoElement) {
  if (!document.pictureInPictureEnabled) return;

  if (document.pictureInPictureElement) {
    await document.exitPictureInPicture();
    return;
  }

  await video.requestPictureInPicture();
}

Three details. Fullscreen the container, or your custom controls disappear behind the browser's. Track state through the fullscreenchange event rather than assuming your call succeeded, because the user can exit with Escape and the browser can refuse. And restore focus to the control that triggered the transition when returning, or a keyboard user is left with focus on the document body.

Picture-in-picture is browser-controlled once active - your controls are gone and the browser's minimal set applies - so keep state in sync via enterpictureinpicture and leavepictureinpicture rather than assuming your UI still governs playback.

Analytics Without Harming Playback

Playback analytics is a business requirement and a performance hazard, because the obvious implementation puts network calls inside media event handlers that run on the frame-rendering thread.

const FLUSH_INTERVAL_MS = 30_000;
const PROGRESS_MILESTONES = [0.1, 0.25, 0.5, 0.75, 0.95];

type PlaybackEvent =
  | { kind: 'startup'; timeToFirstFrameMs: number; startingBitrateBps: number }
  | { kind: 'stall'; atSeconds: number; durationMs: number; bitrateBps: number }
  | { kind: 'bitrate_change'; fromBps: number; toBps: number; reason: string }
  | { kind: 'milestone'; fraction: number }
  | { kind: 'error'; code: string; fatal: boolean }
  | { kind: 'ended'; watchedSeconds: number };

class PlaybackTelemetry {
  private queue: PlaybackEvent[] = [];
  private reachedMilestones = new Set<number>();

  constructor(private sessionId: string) {
    setInterval(() => this.flush(), FLUSH_INTERVAL_MS);

    // 'pagehide' fires reliably on mobile where 'beforeunload' often does not.
    window.addEventListener('pagehide', () => this.flush());
    document.addEventListener('visibilitychange', () => {
      if (document.visibilityState === 'hidden') this.flush();
    });
  }

  record(event: PlaybackEvent) {
    this.queue.push(event);
    // Never send from inside a media event handler. Buffer and flush later.
  }

  /** Called from timeupdate. Must stay trivial - this fires many times a second. */
  onTimeUpdate(currentTime: number, duration: number) {
    if (!duration) return;
    const fraction = currentTime / duration;

    for (const milestone of PROGRESS_MILESTONES) {
      if (fraction >= milestone && !this.reachedMilestones.has(milestone)) {
        this.reachedMilestones.add(milestone);
        this.record({ kind: 'milestone', fraction: milestone });
      }
    }
  }

  private flush() {
    if (this.queue.length === 0) return;

    const payload = JSON.stringify({ sessionId: this.sessionId, events: this.queue });
    this.queue = [];

    // sendBeacon survives the page going away; a plain fetch is cancelled.
    if (navigator.sendBeacon) {
      navigator.sendBeacon('/api/playback-events', payload);
      return;
    }

    void fetch('/api/playback-events', {
      method: 'POST',
      body: payload,
      keepalive: true, // the fetch equivalent, size-limited
    });
  }
}

Four rules:

1. Never send from a media event handler. timeupdate fires up to 66 times a second, and a slow listener on it is a direct cause of dropped frames. Buffer in memory; flush on a timer.
2. Sample continuous signals. Milestones at fixed fractions, not a heartbeat per second.
3. Flush on pagehide and visibilitychange, with sendBeacon. A plain fetch during unload is cancelled, which is why a naive implementation systematically loses exactly the sessions that ended - biasing every completion metric.
4. Measure what viewers experience. The four numbers that matter are time to first frame, stall count and total stall duration, average delivered bitrate, and playback failure rate. Everything else is secondary.

These are field metrics with no server-side equivalent - the server knows which segments it served, not that the viewer watched through four stalls. That is the argument for client instrumentation made in Observability, and the frame-budget reasoning behind rule 1 is in Performance Engineering.

Common Interview Follow-Up Questions

"Playback quality oscillates between 1080p and 480p every few seconds. Why?" The ABR controller is reacting too fast and stepping too far. Three causes, usually together: the throughput estimate weights the most recent sample so heavily that one fast or slow segment swings the decision; the controller jumps directly to the highest affordable rendition instead of stepping up one at a time; and buffer level is not gating upward moves. The fixes are a smoother moving average, a step-up limit of one rendition, a hysteresis requirement that throughput must exceed the next rendition's bitrate by a clear margin before switching up, and a minimum dwell time so quality cannot change on consecutive segments. Downward moves stay fast and upward moves stay slow, because the costs are asymmetric - a stall is much worse than a few seconds at a lower resolution.

"Time to first frame is four seconds. What do you attack?" Break it into its parts and measure each: manifest fetch, first segment fetch, decode and first paint. Common wins in order of impact - serve the manifest from a CDN edge and keep it small, start at a low rendition so the first segment is small, reduce segment duration so the first fetch is shorter, preload the manifest with a resource hint while the page is still rendering, and make sure the poster image is optimised because it is what the viewer looks at during startup and it is the LCP element on most video pages. If the player library itself is large, its download and parse are on the critical path too, which makes code-splitting it a startup optimisation rather than only a bundle-size one.

"How do you resume playback where the viewer left off?" Persist position periodically - every few seconds is enough - keyed by video id and viewer, locally for anonymous viewers and server-side for signed-in ones so it works across devices. On load, seek after loadedmetadata rather than immediately, because currentTime cannot be set before duration is known. Two product details matter more than the mechanism: offer "resume" versus "start over" rather than silently jumping, since a viewer who finished last time does not want to land at 97%, and treat a position within the last few percent as complete and reset it to zero.

"The video is DRM-protected. What changes?" Encrypted Media Extensions enters the picture, along with a license server and platform-specific content decryption modules - Widevine, PlayReady, FairPlay - which means Safari needs FairPlay with HLS while others use Widevine or PlayReady, so packaging and license flows fork by browser. The player gains an encrypted event, a license request round trip, and a whole new class of failure that is unrelated to the network - unsupported CDM, revoked device, insufficient robustness level for the requested resolution. Those failures need their own messaging, because "video unavailable" for a DRM problem sends the viewer looking for a network fault they do not have.

"How do you test a video player?" The controller logic is where the value is, and it is pure: feed the bitrate selector synthetic throughput and buffer sequences and assert it steps down fast, steps up slowly, and does not oscillate under noisy input. The state machine is testable by dispatching synthetic media events, including the awkward orderings real browsers produce - waiting immediately after seeking, error mid-buffering. Integration tests can drive a real element with a short local fixture and assert startup, seek and captions toggling. What cannot be automated is real network variability, so a throttling harness and a manual matrix across browsers and devices remain necessary - and this is one component where synthetic testing genuinely does not substitute for field metrics. The layering rationale is in Testing Strategy.

Tradeoffs Table

Where This Applies

A video player is where the frame budget from Performance Engineering is least forgiving: the decoder and compositor are already consuming the frame, so any main-thread work you add - a heavy timeupdate handler, an analytics call in an event listener, a re-render per second - is visible as dropped frames rather than as a slightly slower page. It is also the clearest case for client-side instrumentation from Observability, because the four metrics that describe playback quality exist only in the browser. And the control bar is a composite widget with real obligations under Accessibility Architecture, where captions are not an enhancement but the feature that decides whether the content is available at all.

Within this track, the poster image and its role as the LCP element connect directly to Image Gallery with Lazy Loading. The buffered-events-flushed-on-hide telemetry pattern is the same one used in Notification System, and the segment fetch loop with backoff and quality fallback is the retry discipline established in File Upload System applied to reads instead of writes.