Build Netflix Adaptive Bitrate Streaming Engine

Consider a garden hose with an adjustable nozzle. When water pressure drops, you tighten the nozzle to maintain a steady stream rather than having the flow sputter and stop. Adaptive bitrate (ABR) streaming does the same thing for video: when your network slows down, the player automatically switches to a lower-resolution version of the content rather than stalling on the highest-quality variant until the buffer drains.

The naive approach - pick a quality level once at start and stick with it - fails instantly in the real world. A viewer on a train passes through a tunnel; their LTE connection drops from 20 Mbps to 0.5 Mbps for 10 seconds. If the player committed to 4K (25 Mbps), the buffer drains in seconds and playback freezes. The player must detect the bandwidth drop and switch to a lower bitrate variant before the freeze happens - while the buffer still has enough content to cover the transition without any visible stutter.

Three tensions define every design decision. Switching speed versus stability: aggressive quality switching detects bandwidth drops quickly but causes frequent visible quality oscillations that annoy users. Buffer target versus startup latency: a larger buffer provides more insurance against bandwidth spikes but delays when playback starts. Optimism versus conservatism: over-estimating available bandwidth leads to rebuffering; under-estimating wastes quality and leaves viewers watching 240p on a 100 Mbps fiber connection.

We need to solve for bandwidth estimation under noisy measurements, buffer management across multi-gigabit and sub-megabit conditions, segment prefetching strategy, and quality ladder design simultaneously.

Requirements and Constraints

Functional Requirements

• Stream video at the highest quality sustainable by the viewer’s current bandwidth
• Switch quality levels seamlessly - no rebuffering during quality transitions
• Minimize time-to-first-frame (TTFF) on initial load
• Recover to high quality within 30 seconds after a network improvement
• Support multiple device classes: TVs (high bitrate), mobile (constrained), smart TVs, game consoles
• Enable server-side per-title quality ladder optimization

Non-Functional Requirements

• 280 million subscribers, peak concurrent streams: ~15 million
• Average session length: 90 minutes
• Rebuffer rate target: less than 0.5% of play seconds result in buffering
• Quality switches: fewer than 3 per minute average
• TTFF: under 2 seconds for 90% of sessions
• CDN cache hit rate: greater than 95% for popular content
• Bitrate range: 235 Kbps (mobile low) to 25 Mbps (4K HDR)

Constraints

• ABR logic runs entirely on the client - the server serves segments on demand, stateless
• CDN serves pre-encoded segments - no real-time transcoding for adaptive delivery
• Segment duration: 4 seconds per segment (Netflix’s production choice)
• Quality ladder is pre-computed per title - not computed at stream time

High-Level Architecture

The system has two distinct sides: server-side infrastructure (encoding pipeline, CDN, manifest service) and client-side ABR logic (bandwidth estimation, buffer management, quality selection). The ABR algorithm runs in the player on the viewer’s device.

A viewer presses play. The manifest service returns a DASH or HLS manifest listing all available quality variants and their segment URLs. The ABR algorithm in the player selects an initial quality level, requests the first segment from the nearest CDN edge node, and starts filling the playback buffer. As segments download, the algorithm continuously re-estimates bandwidth from actual download throughput, compares buffer health against target thresholds, and selects the quality level for the next segment request. This loop runs for every segment for the entire session.

The server side is simpler: an encoding pipeline ingests raw titles and produces segments for every quality level. Segments are stored in origin storage (S3-like object store) and cached at CDN edge nodes globally. The only dynamic component is the manifest service, which returns per-user manifests that can be customized by device capability and user preferences.

The Quality Ladder

The quality ladder is the set of pre-encoded bitrate-resolution pairs available for a title. Think of it as a staircase: the ABR algorithm moves the viewer up or down the stairs based on network conditions.

Netflix does not use a fixed quality ladder. Each title gets its own per-title encoding (Netflix calls this Dynamic Optimizer) where complex scenes get more bits and simple scenes get fewer. But for the ABR algorithm’s perspective, the quality ladder is a fixed ordered list of (bitrate, resolution) pairs available for that title.

A typical quality ladder for a movie:

The codec jump at level 5 from H.264 to H.265 is intentional: H.265 delivers the same visual quality at roughly half the bitrate, but requires hardware decode support. The manifest service checks device capability flags (from device registration at signup) and excludes codec levels the device cannot decode.

DASH Manifest Structure

The manifest (Media Presentation Description in DASH terminology) is the entry point. It lists every representation (quality variant) and the URL template for fetching segments.

<!-- DASH manifest structure (simplified) -->
<?xml version="1.0" encoding="UTF-8"?>
<MPD xmlns="urn:mpeg:dash:schema:mpd:2011"
     mediaPresentationDuration="PT1H52M14S"
     minBufferTime="PT4S"
     type="static">
  <Period>
    <!-- Video adaptation set -->
    <AdaptationSet mimeType="video/mp4" segmentAlignment="true">

      <!-- Quality level 4: 1.75 Mbps 720p -->
      <Representation id="v4" bandwidth="1750000"
                      width="1280" height="720" codecs="avc1.640028">
        <SegmentTemplate
          media="https://cdn.netflix.com/title/123/$RepresentationID$/seg-$Number$.mp4"
          initialization="https://cdn.netflix.com/title/123/$RepresentationID$/init.mp4"
          startNumber="1"
          duration="4"
          timescale="1" />
      </Representation>

      <!-- Quality level 6: 5.8 Mbps 1080p H.265 -->
      <Representation id="v6" bandwidth="5800000"
                      width="1920" height="1080" codecs="hvc1.2.4.L120.90">
        <SegmentTemplate
          media="https://cdn.netflix.com/title/123/$RepresentationID$/seg-$Number$.mp4"
          initialization="https://cdn.netflix.com/title/123/$RepresentationID$/init.mp4"
          startNumber="1"
          duration="4"
          timescale="1" />
      </Representation>

      <!-- ... additional quality levels -->
    </AdaptationSet>

    <!-- Audio adaptation set -->
    <AdaptationSet mimeType="audio/mp4" lang="en">
      <Representation id="a1" bandwidth="192000" codecs="ec-3">
        <SegmentTemplate media="https://cdn.netflix.com/title/123/audio/en/seg-$Number$.mp4"
                         duration="4" timescale="1" />
      </Representation>
    </AdaptationSet>
  </Period>
</MPD>

Each segment is exactly 4 seconds of content. The player downloads segments independently and concatenates them in the media buffer. Because segments are independently decodable (each starts on a keyframe), the player can switch quality between any two adjacent segments without decode artifacts.

Bandwidth Estimation

Bandwidth estimation is the most error-prone component of ABR. The measurements are inherently noisy: TCP slow start inflates early estimates, CDN throughput bursts distort single-segment measurements, and mobile networks fluctuate on a 1-second timescale that is shorter than a 4-second segment.

Netflix’s production ABR uses a combination of two estimators: throughput-based and buffer-based.

Throughput-based estimator measures the actual download speed of the last N segments:

# Exponential moving average bandwidth estimator
from collections import deque

class BandwidthEstimator:
    def __init__(self, alpha: float = 0.7, window: int = 5):
        self.alpha = alpha           # weight on newest measurement
        self.estimates = deque(maxlen=window)
        self.ema = None              # exponential moving average

    def record_download(self, bytes_downloaded: int, duration_ms: float) -> float:
        # Throughput in bits per second
        throughput_bps = (bytes_downloaded * 8) / (duration_ms / 1000)

        if self.ema is None:
            self.ema = throughput_bps
        else:
            # Apply safety factor: use 90% of measured to account for TCP overhead
            safe_throughput = throughput_bps * 0.9
            self.ema = self.alpha * safe_throughput + (1 - self.alpha) * self.ema

        self.estimates.append(throughput_bps)
        return self.ema

    def conservative_estimate(self) -> float:
        if not self.estimates:
            return 0
        # Take harmonic mean of recent measurements to penalize dips
        n = len(self.estimates)
        return n / sum(1.0 / max(e, 1) for e in self.estimates)

Buffer-based estimator (BOLA - Buffer Occupancy-based Lyapunov Algorithm) ignores throughput entirely and uses buffer level as the decision signal. The key insight is that if the buffer is full, we can afford to request a higher-quality segment even if throughput is uncertain; if the buffer is low, we must request a low-quality segment regardless of throughput.

# BOLA-E buffer-based quality selection (simplified)
import math

class BOLASelector:
    def __init__(self, bitrates_bps: list[float], segment_duration_s: float = 4.0):
        self.bitrates = sorted(bitrates_bps)  # ascending order
        self.seg_duration = segment_duration_s
        self.buffer_target_s = 25.0    # target buffer in seconds
        self.buffer_min_s = 10.0       # minimum before quality drop

    def select_quality(self, buffer_level_s: float) -> int:
        # BOLA maps buffer level to utility score using log-based utility
        best_level = 0
        best_score = -float('inf')

        for i, bitrate in enumerate(self.bitrates):
            # Log utility of quality level i
            utility = math.log(bitrate / self.bitrates[0])
            # BOLA score: utility + (buffer - target) / segment_duration
            score = (utility + (buffer_level_s - self.buffer_min_s) / self.seg_duration)
            if score > best_score:
                best_score = score
                best_level = i

        return best_level

In practice, Netflix’s ABR (called “Pensieve”-inspired after their 2017 research) combines both estimators and adds a machine learning component that has been trained on millions of sessions to predict the optimal quality choice given buffer level, throughput history, and remaining content.

Buffer Management

The playback buffer is the shock absorber between network variability and smooth playback. Think of it as a reservoir: downloads fill it, playback drains it at a constant rate (video bitrate), and the ABR algorithm tries to keep it in a target zone - full enough to handle network hiccups but not so full that startup latency suffers.

The buffer state drives three distinct operating modes:

# Buffer state machine for ABR quality control
from enum import Enum, auto

class BufferState(Enum):
    CRITICAL = auto()    # buffer < 5s: force lowest quality, no switching
    LOW = auto()         # buffer 5-15s: conservative, slow quality increases
    STEADY = auto()      # buffer 15-30s: normal ABR operation
    FULL = auto()        # buffer > 30s: pause downloads, let playback drain

class BufferController:
    CRITICAL_THRESHOLD = 5.0     # seconds
    LOW_THRESHOLD = 15.0
    FULL_THRESHOLD = 30.0
    MAX_BUFFER = 60.0            # never buffer more than 60s ahead

    def get_state(self, buffer_s: float) -> BufferState:
        if buffer_s < self.CRITICAL_THRESHOLD:
            return BufferState.CRITICAL
        elif buffer_s < self.LOW_THRESHOLD:
            return BufferState.LOW
        elif buffer_s < self.FULL_THRESHOLD:
            return BufferState.STEADY
        else:
            return BufferState.FULL

    def should_pause_downloads(self, buffer_s: float) -> bool:
        return buffer_s >= self.MAX_BUFFER

    def max_quality_allowed(self, state: BufferState, quality_levels: int) -> int:
        if state == BufferState.CRITICAL:
            return 0  # forced lowest quality
        elif state == BufferState.LOW:
            return quality_levels // 3  # bottom third of ladder
        else:
            return quality_levels - 1  # unrestricted

Segment prefetching strategy is where the buffer management connects to CDN behavior. The player should always have at least 2-3 segments pending download to keep the buffer filling continuously. But over-prefetching wastes bandwidth - if the viewer stops watching at 10 minutes, all segments downloaded beyond 10 minutes were wasted.

Segment Prefetching

Segment prefetching is the mechanism by which the player stays ahead of playback. The player maintains a download queue of upcoming segment requests. The key question is: at what quality level should upcoming segments be fetched?

# Segment prefetch queue manager
from dataclasses import dataclass
from typing import Optional

@dataclass
class SegmentRequest:
    segment_number: int
    quality_level: int
    is_speculative: bool  # True = can be cancelled and re-fetched at higher quality

class PrefetchManager:
    def __init__(self, segment_duration_s: float = 4.0, max_ahead_s: float = 24.0):
        self.segment_duration = segment_duration_s
        self.max_ahead_segments = int(max_ahead_s / segment_duration_s)  # 6 segments
        self.queue: list[SegmentRequest] = []

    def plan_prefetch(
        self,
        current_segment: int,
        abr_quality: int,
        speculative_quality: int,
        buffer_s: float,
    ) -> list[SegmentRequest]:
        requests = []
        # Segments within 12s: download at ABR-selected quality
        firm_count = min(3, self.max_ahead_segments)
        for i in range(1, firm_count + 1):
            requests.append(SegmentRequest(
                segment_number=current_segment + i,
                quality_level=abr_quality,
                is_speculative=False,
            ))
        # Segments 12-24s ahead: speculative lower quality
        for i in range(firm_count + 1, self.max_ahead_segments + 1):
            requests.append(SegmentRequest(
                segment_number=current_segment + i,
                quality_level=speculative_quality,  # lower quality tier
                is_speculative=True,
            ))
        return requests

    def upgrade_speculative(
        self,
        seg_number: int,
        new_quality: int,
    ) -> Optional[SegmentRequest]:
        for req in self.queue:
            if req.segment_number == seg_number and req.is_speculative:
                # Cancel current download, re-request at higher quality
                req.quality_level = new_quality
                req.is_speculative = False
                return req
        return None

Data Model

-- Session telemetry table (used for playback analytics and ABR model training)
CREATE TABLE playback_events (
  event_id          BIGINT GENERATED ALWAYS AS IDENTITY,
  session_id        UUID NOT NULL,
  user_id           BIGINT NOT NULL,
  title_id          BIGINT NOT NULL,
  device_type       VARCHAR(32) NOT NULL,    -- 'tv', 'mobile', 'browser', 'console'
  event_type        VARCHAR(32) NOT NULL,    -- 'quality_switch', 'rebuffer', 'startup', 'abandon'
  occurred_at       TIMESTAMPTZ NOT NULL DEFAULT now(),
  play_position_ms  BIGINT,                  -- ms into content when event occurred
  quality_level     SMALLINT,               -- ladder level at time of event
  buffer_level_ms   INT,                    -- buffer in ms at event time
  bandwidth_est_bps BIGINT,                 -- estimated bandwidth at event time
  segment_number    INT,
  download_ms       INT,                    -- how long segment took to download
  PRIMARY KEY (session_id, event_id)
) PARTITION BY RANGE (occurred_at);
CREATE INDEX ON playback_events (user_id, occurred_at DESC);
CREATE INDEX ON playback_events (title_id, event_type, occurred_at DESC);

-- Quality ladder per title (server-side configuration)
CREATE TABLE title_quality_ladders (
  title_id          BIGINT NOT NULL,
  level             SMALLINT NOT NULL,
  codec             VARCHAR(16) NOT NULL,   -- 'h264', 'h265', 'av1'
  bitrate_bps       INT NOT NULL,
  width             SMALLINT NOT NULL,
  height            SMALLINT NOT NULL,
  hdr               BOOLEAN DEFAULT false,
  segment_base_url  TEXT NOT NULL,
  PRIMARY KEY (title_id, level)
);

-- Device capability registry (determines which ladder levels a device can use)
CREATE TABLE device_capabilities (
  device_id         VARCHAR(128) PRIMARY KEY,
  user_id           BIGINT NOT NULL,
  device_type       VARCHAR(32) NOT NULL,
  max_resolution    VARCHAR(16),            -- '4K', '1080p', '720p'
  supported_codecs  TEXT[] NOT NULL,        -- '{h264,h265,av1}'
  max_bitrate_bps   BIGINT,
  supports_hdr      BOOLEAN DEFAULT false,
  last_seen_at      TIMESTAMPTZ NOT NULL
);
CREATE INDEX ON device_capabilities (user_id);

Key Algorithms and Protocols

EWMA Bandwidth Smoothing with Confidence Intervals

Raw segment throughput measurements are too noisy to use directly. Exponential Weighted Moving Average (EWMA) provides a smoothed estimate while still tracking trends.

# Dual EWMA for fast and slow bandwidth tracking
class DualEWMAEstimator:
    def __init__(self):
        self.fast_alpha = 0.9     # responds quickly to changes
        self.slow_alpha = 0.3     # stable long-term estimate
        self.fast_ema = None
        self.slow_ema = None

    def update(self, throughput_bps: float) -> tuple[float, float]:
        if self.fast_ema is None:
            self.fast_ema = self.slow_ema = throughput_bps
        else:
            self.fast_ema = self.fast_alpha * throughput_bps + (1 - self.fast_alpha) * self.fast_ema
            self.slow_ema = self.slow_alpha * throughput_bps + (1 - self.slow_alpha) * self.slow_ema
        return self.fast_ema, self.slow_ema

    def select_for_quality_decision(self) -> float:
        if self.fast_ema is None:
            return 0
        # During bandwidth drops, fast_ema < slow_ema - use fast to react quickly
        # During bandwidth recovery, use slow to avoid premature upswitch
        if self.fast_ema < self.slow_ema:
            return self.fast_ema  # conservative: react to drops immediately
        else:
            return self.slow_ema  # conservative: delay upswitch until confirmed

Rebuffer Penalty Model

The quality selection algorithm must account for the expected rebuffer probability when choosing a quality level. If estimated bandwidth is 6 Mbps and the requested segment is 8 Mbps, there is a non-zero probability of a rebuffer if the bandwidth estimate was optimistic.

# Expected rebuffer cost for a quality selection decision
import math

def rebuffer_expected_cost(
    estimated_bw_bps: float,
    segment_bitrate_bps: float,
    buffer_level_s: float,
    segment_duration_s: float = 4.0,
    rebuffer_weight: float = 4.3,  # empirically calibrated rebuffer cost
) -> float:
    download_time_s = (segment_bitrate_bps * segment_duration_s) / estimated_bw_bps
    # If download exceeds segment duration, buffer will drain
    if download_time_s <= segment_duration_s:
        return 0.0  # no rebuffer risk
    # Buffer deficit: how much we need minus how much we have
    deficit_s = download_time_s - segment_duration_s
    # Rebuffer probability model (logistic regression on historical data)
    rebuffer_prob = 1 / (1 + math.exp(-2 * (deficit_s - buffer_level_s / 2)))
    return rebuffer_weight * rebuffer_prob * deficit_s

Scaling and Performance

The server-side scales through the CDN layer, not through the ABR logic (which runs client-side). The key server scaling challenge is CDN cache hit rate.

Capacity Estimation:

Given:
  - 280M subscribers, peak 15M concurrent streams
  - Average bitrate: 4 Mbps (mix of quality levels)
  - Segment duration: 4 seconds

Bandwidth at peak:
  - 15M streams x 4 Mbps = 60 Tbps total egress
  - Distributed across ~1,000+ CDN edge PoPs globally
  - Per PoP average: 60 Gbps (varies 5x by geography)

Segment storage per title:
  - 10 quality levels x 4 Mbps average x 2 hours = ~288 GB per title (H.265)
  - 15,000 titles active = ~4.3 PB of active content cache across CDN

CDN cache eviction:
  - Long tail titles: LRU eviction from PoP cache, warm from regional origin
  - Popular titles (top 1000): pinned permanently at all major PoPs
  - New releases: pre-warmed to edge nodes before premiere time

CDN pre-warming is critical for new releases: if 10 million subscribers try to watch a new season premiere simultaneously and the first segment request at each PoP misses the cache, origin traffic spikes 10-100x. Netflix pre-stages content at edge nodes 1-2 hours before a scheduled release using a background crawl that requests every segment at every quality level across every PoP.

Failure Modes and Recovery

Comparison of Approaches

The hybrid approach combining buffer occupancy and throughput estimation is the right production choice. Pure throughput-based ABR (like the original HLS implementation) oscillates badly on mobile networks. Pure buffer-based ABR (BOLA alone) reacts too slowly to sudden bandwidth spikes, leaving quality lower than necessary. The ML approach (Pensieve) achieves the best results but requires significant on-device compute and ongoing model training infrastructure.

Key Takeaways

• The ABR loop is a control system where output quality affects future throughput measurements through TCP congestion and CDN behavior - buffer-based control breaks this coupling for more stable operation.
• DASH manifests are the contract between server and client - segment duration choice (4 seconds at Netflix) directly trades switching granularity for manifest complexity and connection overhead.
• Dual EWMA with fast and slow trackers detects bandwidth drops quickly while delaying upswitch decisions, asymmetrically trading worse-case quality recovery for lower rebuffer rates.
• The rebuffer penalty weight (4.3x at Netflix) is a product decision as much as an engineering one - it encodes how much users prefer avoiding rebuffers versus watching lower quality.
• CDN pre-warming for major releases is as important as the ABR algorithm itself - a perfect ABR cannot compensate for origin-miss latency at scale.
• Per-title encoding ladders (VMAF-based) rather than fixed bitrate ladders significantly reduce storage and bandwidth for complex titles while improving quality for simple ones.
• Quality hysteresis (requiring 20% bandwidth headroom before switching up) prevents oscillation at the cost of slightly slower quality recovery - almost always the right tradeoff.

The counter-intuitive lesson: the ABR algorithm is not trying to maximize video quality. It is trying to maximize a combined utility function where rebuffering is penalized ~4x more than equivalent quality reduction. Users tolerate lower quality far better than they tolerate freezing - the algorithm is optimizing for perceived experience, not for a raw quality metric.

Frequently Asked Questions

Q: Why use DASH instead of HLS? Netflix uses both - when does each win?

A: HLS (HTTP Live Streaming) is Apple-native and required for iOS/Safari. DASH (Dynamic Adaptive Streaming over HTTP) is the ISO standard with better codec flexibility and lower manifest overhead. Netflix serves HLS to Apple devices and DASH everywhere else. The ABR algorithm is essentially identical - only the manifest format differs. DASH supports more advanced features like multi-period streams and subsegment addressing, which matter for live streaming.

Q: How does ABR handle 4-second segment boundaries? Can quality change mid-segment?

A: No - quality changes only happen at segment boundaries, since each segment starts with an independently decodable keyframe (IDR frame in H.264/H.265). This means the finest granularity of quality switching is 4 seconds. The segment duration is a product tradeoff: shorter segments (1-2s) allow finer adaptation but increase HTTP overhead and manifest size; longer segments (8-10s) reduce overhead but make the system sluggish on mobile. 4 seconds is Netflix’s empirical optimum.

Q: Why not just use larger buffers everywhere to eliminate rebuffering entirely?

A: Larger buffers increase startup latency (you must fill the buffer before playback starts, or start low-quality) and waste bandwidth when users quit early - which they frequently do. Netflix measures that 30% of sessions end within the first 2 minutes. A 60-second buffer on a 10 Mbps connection wastes ~75 MB per session of abandoned downloads. The 30-second target buffer is the empirical minimum that provides near-zero rebuffer rates under realistic network variability.

Q: How does ABR interact with DRM decryption? Do encrypted segments complicate bandwidth estimation?

A: DRM encryption (Widevine on Android, FairPlay on iOS) operates at the segment level - each segment is independently encrypted. From the ABR algorithm’s perspective, the encrypted and decrypted segment sizes are nearly identical (AES-CBC adds negligible overhead). The decryption happens in a trusted execution environment (TEE) on the device after download, so it does not affect bandwidth estimation. The license fetch (Widevine license server) adds 100-300ms of latency on initial load but is cached per session.

Q: Why pre-encode all quality levels instead of transcoding on the fly per viewer?

A: Real-time per-viewer transcoding would require encode capacity proportional to concurrent viewers (15 million encoders at peak). Pre-encoding amortizes this cost across all viewers of the same title. The tradeoff is storage: 10 quality levels x average 288 GB per title requires significant CDN storage. Netflix’s per-title encoding optimization (different bitrate ladders per title complexity) recovers roughly 30-40% of that storage cost while improving quality for complex content.

Interview Questions

Q: Walk me through the full lifecycle of a quality switch from 1080p to 720p.

Expected depth: Discuss bandwidth estimator triggering the decision (throughput drop or buffer drain), the decision to request the next segment at level 4 instead of level 6, that the switch only takes effect at the next segment boundary (not mid-segment), that the init segment for the new quality must be fetched first if it was not previously buffered, and how the decoder handles the resolution change between back-to-back segments.

Q: How would you design the ABR algorithm to handle a viewer who pauses for 5 minutes then resumes?

Expected depth: Cover buffer state during pause (buffer full, downloads paused), bandwidth estimate staleness (measurements are 5 minutes old), whether to resume at current quality or drop one level as a safety margin, how to handle CDN connection keepalive during the pause, and the cold-start bandwidth probe strategy (start conservative, ramp up within 2 segments).

Q: The rebuffer rate is spiking for users on a specific ISP in Brazil. What do you investigate?

Expected depth: Discuss CDN PoP health for that geographic region (check origin pull rate - high origin pull means PoP cache is missing), bandwidth estimator behavior for that ISP’s throughput profile (is EWMA miscalibrated for the specific congestion patterns?), whether the quality ladder’s lowest rung is low enough for constrained connections, and whether the ABR hysteresis setting is appropriate for that network’s volatility pattern.

Q: How would you add support for live streaming (not just VOD) to this architecture?

Expected depth: Discuss manifest type change (type=“dynamic” in DASH), segment numbering and availability window (only the last N segments are valid), buffer target reduction (live streams cannot buffer far ahead), latency tradeoff (deeper buffer = more stable = more latency behind live edge), keyframe alignment requirements for live encoding, and how CDN caching works for live segments (short TTL, segment availability window).