One stack for every video surface
Facebook’s video delivery spans three systems: ranking, server, and mobile. The ranking system, RecSys, generates candidate content based on short-term, long-term, and real-time user interests. The server layer (WWW) brokers between clients and RecSys, handling pagination, deduplication, and signal collection while managing capacity via caching and throttling. On mobile, Facebook for Android and Facebook for iOS use client-side ranking (CSR) to deliver optimal content at the point of consumption without a round trip to the server.
Tight latency budgets sit at the heart of these systems. Ranking models must deploy quickly, favor fresh content—content generated recently by ranking—and support flexible optimization functions and value modeling.
Why consolidate?
For years, Facebook Watch and Reels operated as separate products with separate client layers, server layers, and ranking stacks. That fragmentation hurt users and developers alike. Engineers had to maintain multiple codebases that couldn't share improvements, leading to inconsistent experiences. Creators had to produce different content types—Reels for immersive surfaces and VOD for the Watch tab—to reach the same audience. Advertisers faced the same duplication across ad formats.
Unification addressed all of that at once: one UI paradigm for video, one set of underlying data models, and one architecture from ranking to client.
Merging the technical stack
Unifying the client and server data models and architectures took a year. The effort spanned iOS, Android, and the server with no visible change to the user interface.
The complexity came from several directions:
- A user base in the billions, meaning any unintended shift in logging, UI, or performance would show up instantly in top-line metrics.
- Tens of thousands of lines of code per layer on each platform.
- Merging Reels and Watch required auditing hundreds of features and thousands of lines of code to preserve every key experience.
- Logging needed to stay consistent while the code beneath it changed, and hundreds of logging parameters had to be re-implemented to serve both products.
- Product engineers kept shipping new features on the old Reels and Watch systems while the unified stack was being built, creating a moving target. Transferring engineers too early would have put roughly 50 product engineers' goals at risk; transferring too late would have meant porting even more old features onto the new infrastructure.
Engagement and performance metrics were held to the same bar throughout the migration.
Migrating users to a unified surface
With the backend consolidated, the next step was moving every VOD feed-chaining experience to the immersive Reels UI. That UI was designed for short-form, while the old Watch surface was optimized for long-form viewing. It took hundreds of tests and a year of product iterations to arrive at a video feature set that served both content types without compromise.
A single ranking layer
The final infrastructure layer to consolidate was ranking, shipped in August 2024. Ranking had to wait because it depends on consistent signals from the UI. A Like on the Reels UI—a prominent button on the vertical sidebar—and a Like on the Watch UI (bottom left) carry different contextual weight. Treating them as identical would degrade recommendations.
Beyond UI parity, ranking had to handle a mixed inventory of Reels and VOD content. The ranking team unified their data, infrastructure, and algorithmic foundations across both stacks, built a single content pool holding short-form and long-form video, and tuned the recommendation models to avoid video-length bias. That let users who leaned heavily toward Reels or toward Watch transition into one recommendation experience without preference shocks.
Unified video tab
The effort culminated in the unified video tab: a Reels-like immersive UI, unified ranking, and shared product infrastructure serving Reels, long-form VOD, and live content. This consolidated experience provides a singular path to delivery and paves the way for integrations across the stack. Given client-side ranking and the server layer's combined power, the Facebook app can finally present freshness and relevance together.
A closer look at Facebook’s video delivery stack
Facebook’s video delivery system is built around five operating principles: prioritizing fresh content, letting ranking decide the order of content, vending content only when needed (and as little as possible), keeping fetching behavior deterministic, and showing content only when there is a clear signal that the person wants it.
Anatomy of a feed request
On the mobile client, several mechanisms can start a network request. A prefetch request fires shortly after app startup, before the surface is visible, but only for the tab surface. A head load is the initial request triggered by navigation to the surface; every subsequent request is a tail load, triggered by scrolling. Prefetch and head load can be in flight at the same time, and the client vends whichever returns first. If both are too slow, it falls back to cached content.
Tail loads work differently: a request is issued on scroll only if the in-memory pool (the client-side store of video stories ready for viewing) holds three or fewer network-sourced stories. Four cached stories will not suppress a network request. Tail load requests also carry user signals that ranking uses to generate candidate videos.
Server-side layers
An incoming GraphQL request first hits the GraphQL framework and the schema for the video data model, then the video delivery stack — a generalized service layer that can back any Facebook video experience through feeds, databases like TAO, caches, or other backend systems. Profile video tabs, soundtrack or hashtag video lists, and the main video tab all go through this stack.
For the video tab, the request then enters the Feed stack, shared infrastructure used to build and configure News Feed, Marketplace, Groups, and other feed types. The video tab’s feed implementation calls into the ranking backend. Along the way the server applies significant business logic: throttling under data-center capacity constraints or disaster recovery, caching ranking results, pulling model input data from multiple stores, tracing latency, and piping client parameters to ranking.
Ranking and the response path
Ranking runs as a graph-based execution service that orchestrates the full serving workflow. The recommendation pipeline includes candidate retrieval from multiple ML retrieval models, filtering, point-wise and list-wise ranking, and heuristic diversity control. Every candidate must survive all stages to be delivered. Additional features include using a root video to contextualize the top stories and elastic ranking, a framework that dynamically adjusts ranking-query variants based on system load and capacity.
Ranking returns a list of video IDs and per-item metadata. The server then loads the full video entities from TAO and runs privacy checks, which are defined server-side because ranking lacks the logic to perform them (though it applies heuristics to cut down on recommending videos a viewer cannot access). The GraphQL framework then materializes the fields the client requested. Privacy checks and materialization together are a meaningful share of global data-center CPU usage, making optimization there a key lever on power demand.
Client-side merging and the freshness/perf tradeoff
When the network response arrives, the client adds the stories to the in-memory pool, ordering them by the server-provided sort key from ranking and by whether the person has already viewed them. That defers prioritization to ranking, which has richer recommendation logic than the client, and keeps fresh content at the front.
The core tension on mobile is content freshness versus performance and efficiency. Waiting too long for a network response drives people away; instantly vendoring cache means the first content shown may be stale and irrelevant. Fetching too often raises capacity costs; fetching too little leaves network content unavailable and stale content on screen. When stories move from the pool into view, the client also prefetches media so swiping between videos is seamless.
Dynamic pagination
Standard delivery gives every user a fixed-size page of videos from ranking to client, which is wasteful across a user base that ranges from people who never swipe to heavy consumers. Facebook’s dynamic pagination framework shifts control over page size to ranking.
Under this scheme, ranking decides how many videos to rank and serve for a given person. The server enforces a deterministic page-size contract between server and client — the contract between ranking and server is dynamic, while the one between server and client is fixed at the smallest possible value. That prevents a device from receiving an oversized ranked batch and keeps client infrastructure simple.
Ranking can now personalize batch size to its confidence: a larger set of ranked content when it understands the person’s consumption patterns, a smaller set when it does not. Newer users get carefully curated smaller batches while regular users receive larger recommendation sets, conserving capacity across the system.
Real-time ranking
Real-time ranking adapts video ordering based on interactions such as view time, likes, and other engagement signals. Those signals can flow through asynchronous data pipelines for accurate ranking or via synchronous paths, such as piggybacking a batch onto the next tail load. The choice depends on system latency and signal completeness; when the real-time signal snapshot is similar between two ranking requests, ranking has little to react to.
The mechanism is meant to keep relevant, engaging content prominent, eliminate duplicates, and enable exploration of new topics — a more personalized viewing experience that adjusts within a session based on behavior. Responsiveness in this context measures how well and consistently the end-to-end infrastructure delivers fresh content.
