The mid-film seek is the whole cache design

Ask what a cache should do and you get an answer about hit ratios. Ask what a video cache should do and the answer is: survive somebody skipping the first ninety minutes.

Why that one interaction dominates

A seek produces a range request into the middle of a large object. Three things follow immediately.

1. The bytes requested may never have been fetched before, so this is a miss on an object the cache is otherwise holding.
2. The bytes before them are irrelevant, so fetching the object from the start is wasted work at the one moment latency is visible.
3. The viewer is waiting. A seek is the one moment where a stall is blamed on the service and not on the network.

Slice-based storage

Objects are stored as fixed slices, addressed by content hash. A range maps onto the slices it overlaps; only those are fetched.

# Slice arithmetic for a 2 MB slice size.
#   seek to 01:30:00 in a 4.1 GB rendition
#   byte offset ≈ 2,415,919,104
#   slice index  = offset / 2 MB = 1152
#   fetch slices 1152..1157 (six), serve, cache
#
# The next viewer who seeks anywhere in that ten-second
# neighbourhood is served from disk.

Slice size is the one tunable that matters, and it is a trade between two bad extremes. Too small and the index dominates. Too large and a seek fetches material that goes unwatched, which is the whole-object problem with extra steps.

Content classes behave differently

A blended hit ratio hides the case that hurts. Splitting by class is what makes the number actionable.

Sharing one policy across all three lets the live surge evict the long tail's working set at every event. The archive's hit ratio then collapses in a way the overall average never shows.