# F3 Lightning: Scaling Meta's Ads Machine Learning Feature Production Meta decouples feature releases from shared execution to accelerate model deployment cycles. - **Source:** [Facebook Engineering](https://engineering.fb.com) - **Published:** 2026-11-03 - **Topic:** [Software & Engineering](https://brifing.si/c/engineering) - **Original article:** - **On Brifing:** https://brifing.si/s/23b2429a-9fa6-4140-8513-c4e2bd9c7c8f ## The F3 Scaling Challenge Meta originally utilized the Facebook Feature Framework to manage over 20,000 machine learning features for ads ranking. The system compiled features into a single merged graph to optimize computational costs. However, this architecture created a rigid release unit where a single malformed feature definition blocked the entire deployment pipeline for all features. ## Introducing F3 Lightning F3 Lightning acts as an infrastructure layer built atop the existing F3 framework to decouple feature releases from shared execution. This design allows engineers to compile, validate, and deploy features independently. By separating the release boundary from the execution boundary, Meta successfully prevents individual feature failures from stalling the entire production pipeline. ## Maintaining Computational Efficiency Early prototypes of per-feature releases suffered from increased CPU usage because independent features lost the benefits of shared computation. To achieve efficiency parity, Meta implemented four specific optimizations: stable computation identifiers, a single shared execution plan, a unified memory buffer, and dense index mapping. These ensure that no redundant work occurs during requests. ## Stable Computation Identifiers To deduplicate execution, the runtime must recognize identical computations across independently compiled configurations. F3 Lightning derives identifiers based on the operation, its parameters, and input identifiers rather than local node numbers. This global consistency ensures that two features using the same logic receive identical identifiers, even if they were compiled weeks apart. ## Unified Execution Planning At service startup, F3 Lightning constructs a single execution plan using a topological sort to order dependencies. When multiple features share a node, the plan retains only one copy, ensuring the computation runs exactly once per request. The system flattens this graph into an ordered list to facilitate a single forward pass during runtime. ## Shared Memory Buffer Optimization F3 Lightning replaces per-feature data containers with a single memory buffer per request. This change improves data locality, as consecutive plan steps access adjacent memory, significantly reducing cache misses. Furthermore, it eliminates redundant copies of feature values, as consumers now reference the producer's result directly within the shared buffer space instead of copying. ## Dense Index Mapping To minimize access costs, F3 Lightning assigns every unique identifier a consecutive integer slot at startup. This allows the system to rewrite references to point directly at these slots, removing the need for hashing or pointer following during the request path. Reading a result becomes a direct array index, maximizing performance at scale. ## Deployment Granularity Benefits Features are now selected from a priority queue based on impact and risk rather than being batched. New, low-risk features can be released rapidly using standard validation, while modifications to live models undergo more rigorous testing. This granular approach significantly shortens the release cycle, enabling more frequent model iterations and faster production updates. ## Resilience Against Failures The new architecture ensures that a single failing computation does not crash the entire system. If a specific node fails, F3 Lightning marks all downstream dependencies as not ready and skips that branch. Independent features continue to execute normally, maintaining overall system availability despite isolated errors in the feature graph definitions. ## Performance and Speed Gains Comparable extraction features now reach production approximately 3.6 times faster than under the previous F3 framework. Crucially, these improvements were achieved without increasing infrastructure computational costs. The ability to iterate faster allows Meta to retrain and improve ads ranking models more frequently, directly enhancing the effectiveness of their advertising systems. ## Lessons in System Design The project highlights that deployment and execution boundaries should remain separate to avoid release bottlenecks. Furthermore, Meta learned that work which remains constant between requests belongs at startup, not on the request path. These architectural shifts allowed the team to remove repeated computations while keeping the system highly performant and stable. ## The Importance of Memory A key takeaway from F3 Lightning is that memory layout is as critical as computational logic. Even when redundant operations are removed, CPU usage can remain high if results are scattered across memory. Consolidating results into one copy per value was the most effective optimization for closing the performance gap in this system. ## Sources covering this story - https://engineering.fb.com/2026/11/03/ml-applications/f3-lightning-how-meta-accelerates-ads-ml-features-to-production/ — --- _Summary written by Brifing from the original reporting. Copyright in the original article belongs to its publisher; read the full piece at the link above._