Inside Facebook's Video Delivery System
How Meta unified Watch and Reels into a single video stack, and the five delivery principles governing how billions of people receive video content on Facebook.
You assume the hard part of video delivery is the codec — picking the right compression algorithm, tuning bitrates. But Meta’s account of building Facebook’s video system reveals that the codec barely registers in the complexity budget. The real work is in the contracts between layers: who decides what to show, when to ask for more, and how to stay honest about what “fresh” actually means when you’re managing billions of sessions simultaneously.
Source
Inside Facebook’s video delivery system
By: Meta
Published: Dec 10 2024
Type: Engineering article
A rare end-to-end account of a production video pipeline — from the moment a user navigates to the tab through ranking, server brokering, and mobile vending. Worth keeping because it names the tradeoffs explicitly rather than glossing over them.
How Facebook’s three-layer video stack actually works
The delivery system rests on three distinct layers with clearly separated concerns. Ranking (RecSys) recommends content based on short-term, long-term, and real-time interest signals. The server layer (WWW) brokers between mobile clients and ranking — handling pagination, deduplication, caching, and capacity throttling. Mobile handles the final mile: managing an in-memory pool, deciding when to fetch, and prefetching media so swipes feel instant.
Each layer has a single job, and the contracts between them are explicit. The server-to-client contract is a fixed page size. The ranking-to-server contract is dynamic — ranking can vary how many videos it returns based on confidence in its model of that person’s consumption behavior. A new user might get a small, carefully curated batch. A heavy daily user gets a larger recommendation window. This dynamic pagination framework lets Meta conserve capacity without degrading the experience for either extreme.
The five delivery principles encode a lot of hard-won judgment: prioritize fresh content, defer ordering decisions to ranking, vend as little as possible only when needed, keep fetching behavior deterministic, and only serve content when there’s a clear signal someone wants it. The last one in particular runs against the instinct to preload aggressively. Meta discovered that over-fetching both wastes capacity and trains ranking on misleading engagement signals — a video technically “delivered” to a pool that was never scrolled to doesn’t tell you anything useful.
Client-side fetch logic is where these principles get tested. A prefetch fires shortly after app startup, before the user navigates to the video tab. A head load fires when they arrive. Tail loads fire on scroll, but only if the in-memory pool has three or fewer network-sourced stories. If it has four cache stories and four network stories, the count is what matters — not whether the content is fresh. This asymmetry is intentional: stale content triggers a network request, abundant network content suppresses one. Getting those thresholds wrong in either direction shows up directly in engagement and capacity costs.
Real-time ranking tightens the feedback loop between consumption and recommendation. User signals — watch time, likes, skips — flow back to ranking either asynchronously via data pipelines or synchronously piggybacked onto the next tail load. The catch: if two consecutive ranking requests see nearly identical signal snapshots, ranking has nothing new to act on. The responsiveness of the system depends on enough signal delta accumulating between requests, which is partly why throttling fetch frequency too aggressively can quietly degrade recommendation quality even when delivery feels fine.
One detail that doesn’t get enough attention: client-side ranking (CSR) lets the mobile app reorder content at consumption time without a server round trip. This matters because the moment someone pulls out their phone and opens the video tab, network latency introduces a window where the server’s sort order might already be stale. CSR closes that window by using local signals — what the person is doing right now, not what ranking predicted they’d want 200ms ago. It’s a delegation of ranking authority to the device, bounded by what the server already sent down.
The two-year video unification effort is what made any of this possible. Before unification, Facebook Watch and Reels ran separate mobile clients, server stacks, and ranking layers. A Like on the Reels UI sat prominently on the right sidebar. On the Watch UI it was at the bottom left. Same signal, completely different context. Feeding both into a shared ranking model without accounting for that would have degraded recommendations across the board. The unification forced the team to resolve those contextual inconsistencies before ranking could treat them as equivalent inputs.
The server layer handles privacy checking and field materialization after ranking returns a list of video IDs. These two steps together represent a “meaningful portion of global CPU usage” in Meta’s data centers — a detail that makes clear why ranking can’t simply own the full end-to-end pipeline. Privacy logic lives on the server; ranking works around it with heuristics to reduce the frequency of recommending videos the viewer won’t be allowed to see. The boundary is enforced, not assumed.
My take
The unification story is really a story about the cost of architectural drift. Watch and Reels were solving the same problem with different codebases, different UI contexts, and different signal interpretations. Each team kept shipping — improving their own surface — which created a moving target for anyone trying to merge them. The “50 product engineers blocked if we transfer too early” calculation is exactly the kind of tradeoff that gets made in the abstract but rarely written down. The fact that Meta committed to it and documented the reasoning is the actually interesting part.
The deeper observation: freshness and ranking quality pull against each other unless you’re careful. Serving cache instantly keeps engagement metrics high in the short term. But if cache content is stale, ranking learns from engagement with old recommendations, which compounds into worse future recommendations. The five principles exist to resist short-term metric optimization at the expense of the recommendation loop.
Where this is useful
- Designing a content feed where ranking and delivery are owned by separate teams
- Reasoning about fetch frequency tradeoffs when capacity and engagement both matter
- Building a pagination model that handles highly variable consumption patterns across a user base
- When NOT applicable: small-scale feeds where ranking and delivery are colocated and capacity isn’t a constraint
Apply this: Before setting a prefetch or pagination threshold, write down what signal you’re trying to capture and what gets corrupted if you over-serve from cache.
What I want to remember
Remember: The contract between layers matters more than what any individual layer does — fixed page size to the client, dynamic page size from ranking, with the server holding the guardrail.