Design the service that generates and serves the streaming manifests players read to do adaptive-bitrate playback. A manifest describes the rendition ladder for an asset and the ordered list of media segments; the player fetches it first and re-fetches it to adapt. Your service must produce the right manifest for each request, fast, for both video-on-demand and live.

Operating context. The catalog holds tens of millions of VOD assets, each transcoded into several renditions, plus thousands of concurrent live channels. The advertised rendition ladder must be tailored per request by device capability, region, and the viewer's entitlement tier, and segment URLs must be rewritten to the correct CDN edge with a signed token. VOD manifests are highly cacheable; live manifests change every few seconds as new segments publish.

Out of scope. The transcoding that produces renditions, DRM key delivery, the player's rendition-selection algorithm, the CDN's own cache configuration, and the entitlement service's internal logic (assume it exposes a fast check). Assume separate teams own those.

What to produce. A high-level architecture covering: the manifest data model, the generation paths for VOD versus live, how the ladder is filtered per request by device/region/entitlement, the caching strategy and invalidation, how live manifests stay fresh as segments publish, and how segment URLs are signed and rewritten to the edge. Sketch the components and the request flow; we will probe specifics during checkpoints.