Meta: feed & ads, and how Meta ships

I would split it into candidate generation, ranking and serving. Candidates come from the social graph plus recommended content, pulled at read time so celebrity posts do not fan out to millions of inboxes. Ranking is multi-stage: a cheap model narrows thousands of posts to a few hundred, then a heavy neural model predicts probabilities of like, comment, share and hide, combined with weights into one score. Integrity filters and demotes before blending, and ads are auctioned separately and slotted in with frequency limits. Every impression and action is logged to a stream that updates features and retrains models. I would discuss latency budgets, caching of the graph, fallbacks to a simpler ranker, and offline versus online evaluation through A/B tests.

The client calls the feed service with the user's identity and device context. The service reads the user's connections from the social graph and gathers an inventory of recent eligible posts plus recommended content. Staged ranking narrows thousands of candidates. Cheap retrieval and light models go first, then heavy neural models predict actions such as like, comment, share and hide. Integrity filters remove violating posts and demote borderline ones. In parallel, the ads system runs an auction for eligible ads. A blender interleaves organic posts and ads, applies diversity and frequency rules, and returns a page. Impressions, clicks, dwell time and hides stream back into logging pipelines, which refresh features and retrain models.

It is a cost and latency trade-off. The inventory can hold thousands of candidates, and running a large neural model on each one inside an interactive latency budget would be far too expensive across billions of requests. So each stage trades accuracy for throughput. Retrieval uses embeddings or simple heuristics to pull a broad set. A lightweight model prunes it to a few hundred. The heavy multi-task model then scores only that short list, and final re-ranking applies business and integrity rules. The risk is that early stages drop good candidates the heavy model would have liked. I'd measure recall of each stage against the final ranker, and occasionally run the heavier model on wider slices offline to check what is being lost.

I'd use defence in depth rather than one check at render time. At upload, run classifiers for clear policy violations and block or hold high-confidence cases. Store integrity scores and enforcement state keyed by content id, so feed serving does a cheap lookup. At ranking time, filter anything removed and demote borderline or low-quality content using those signals. Re-score content asynchronously when models improve or when reports and virality spike, because risk changes over time. Uncertain cases go to human review queues, prioritised by expected reach. Removal needs high precision. Demotion can tolerate more false positives because the cost is lower. I'd also track prevalence, meaning how often violating content is actually seen, as the outcome metric.

Highest bid alone would show ads people don't respond to or dislike. That hurts users, and over time it hurts advertisers and the platform too. Meta publicly describes total value as combining the advertiser's bid, the estimated action rate and ad quality. A modest bidder with a highly relevant ad can therefore beat a large bid on an irrelevant one. This lines up incentives: advertisers do better by making relevant ads, and users see fewer low-quality ones. The engineering consequence is that estimated action rates must be well calibrated and ad-quality signals must be trustworthy. Errors in either one shift auction outcomes and spend, not just ranking order.

Design fallbacks in tiers. If the heavy model times out, use the lightweight ranker's order. If ranking is unavailable, serve a recency or cached ranked feed, with integrity filtering still applied. If the ads auction misses its deadline, return the page with fewer ads rather than blocking. Load shedding drops optional work first, such as extra recommendation sources. For regional failure, traffic shifts to healthy regions, which need capacity headroom. Replicated stores and caches let reads continue, with some staleness accepted. Regular disaster-recovery drills, including deliberately taking capacity out, are the only way to know this actually works.

First I separate deploying code from releasing behaviour. The code ships through review and continuous deployment, but the new path is off behind a feature flag. I enable it for employees, then a small random percentage of users in an A/B test with a clear hypothesis and guardrail metrics: latency, crashes, integrity prevalence, and long-term engagement, not just clicks. I watch dashboards during ramp, and if a guardrail breaks I turn the flag off immediately rather than waiting for a revert. I would also keep a long-term holdout to catch slow effects, and once the result is clear, remove the flag and dead code.

In a past role we needed to replace a slow recommendation endpoint before a festival sale. I shipped the new version within a week, but behind a flag, with the old path kept as fallback. I added latency and error alerts, rolled out to five percent of traffic, and compared conversion and error rates against control. On day two we saw timeouts in one region caused by a cold cache; I turned the flag down for that region, fixed cache warming and resumed. We reached full traffic before the sale. What I learned matches Meta's publicly described culture: speed comes from small reversible steps and ownership, including being on-call for what you ship.

A common design is a multi-task model that outputs calibrated probabilities for each action. A value function then combines them as a weighted sum, with negative weights for actions like hide or report. The weights express product judgement about what counts as meaningful engagement, so they are tuned through A/B tests rather than learned purely from clicks. The probabilities need to be calibrated, or the weights stop meaning what we think they mean. I'd keep the value function in configuration behind a flag so teams can experiment safely. I'd also track guardrails such as hides, reports and time-well-spent surveys, so that optimising one action does not quietly harm the experience.

Meta's TAO paper describes two primitives: objects and associations. Objects are typed nodes with an id and key-value data, such as a user, post, comment or page. Associations are typed, directed edges between two objects, with a timestamp and a small payload. Examples are 'friend', 'authored', 'liked' and 'commented-on'. Many edge types have an inverse, so writes may update both directions. The key query is association range: give me the newest N edges of type T from object X, ordered by time. That fits feeds and comment lists well. Storage is sharded MySQL with a graph-aware cache tier in front, because the workload is overwhelmingly reads.

I'd start from a target for the server-side page response and then allocate it across stages. Graph and inventory reads need to be fast, which means parallel fan-out to cached shards. Retrieval and light ranking should be cheap. The heavy model usually gets the largest share. Integrity lookups should mostly be precomputed scores fetched by post id, not inline inference. The ads auction runs in parallel with organic ranking, so it adds little to the critical path if it finishes in time. I'd set per-stage timeouts and use hedged requests for tail latency. If a stage overruns, the system degrades instead of blocking. For example, it skips an optional ranker or serves a cached candidate set. I'd monitor p99, not averages.

Most of the system can be eventually consistent, but users expect read-your-own-writes for their own actions. TAO, as publicly described, routes writes to a leader for each shard. Follower caches in other regions update asynchronously, so a refresh served from a lagging replica could miss the post. Options include routing the author's reads to the leader for a short window after a write. Another is to have the client optimistically insert the new post locally. A third is a session marker that tells the feed service to fetch the author's latest posts from the source. For other viewers, a few seconds of lag is acceptable, so we don't pay for strong consistency globally.

It depends on the signal. For known removals and hard blocks, enforcement state must be durable and replicated, so it is effectively always available. Content already marked removed should never be served, even in degraded mode. For fresh, unscored content, I'd lean towards fail-closed for risky surfaces. That means holding back unscored items, or serving only content from connections and established sources, rather than surfacing unknown recommended content to many people. Borderline demotions can fail open briefly, because their absence is a quality issue, not a safety breach. Either way, the outage should page someone, show up on dashboards, and be time-limited by design.

A strongly consistent global counter checked on every auction would be too slow. Instead, I'd use pacing. A central budget service computes a spend rate per campaign and hands out allowances or throttle probabilities to ad servers. Each server spends locally and reports spend asynchronously through a stream. The controller adjusts pacing as reported spend approaches the budget, smoothing delivery across the day instead of exhausting it early. Because reporting lags, small overspend is possible, and policies need to define how that is handled. Billing events must be deduplicated and reconciled against impression logs, so the source of truth for money is the reconciled ledger, not the real-time estimate.

I'd give every impression a unique id generated where it is served, and make downstream consumers idempotent on that id. Streaming systems are usually at-least-once, so duplicates are expected and deduplicated. Client events can be lost or replayed, so I'd define server-side and client-side impressions clearly and reconcile the two. Training pipelines can tolerate small loss but not bias, so I'd monitor event volumes by app version and region to catch silent drops. Billing needs stronger guarantees, so it uses a separate, audited path with deduplication, retention and reconciliation jobs. Schema changes go through versioning so a logging change can't break consumers.

Skew happens when the features a model sees in training differ from those it sees at serving time. Causes include different code paths, different freshness, or leakage of information that wouldn't exist at request time. The best prevention is to log the exact feature values used at serving time alongside the request. Then you train on those logged features instead of recomputing them later. Use a shared feature definition for online and offline. Make point-in-time correctness a rule, so training never uses data from after the impression. I'd also compare online prediction distributions against offline ones, and alert on calibration drift when a model or feature pipeline changes.

First, I'd check the experiment is valid: sample ratio, correct exposure logging, enough power, and no bugs in serving the new model. Then I'd look for skew between offline features and live ones, and check online calibration. Offline metrics measure prediction accuracy on logged data shown by the old model. Better predictions don't always change rankings, and the value function may not reward the improvement. I'd analyse segments such as new users, heavy users and regions, because a gain in one may be cancelled by a loss in another. If it's genuinely neutral, I wouldn't ship added complexity just because offline numbers look good. The online result decides.

Users interact, so treatment can leak into control. If treatment users share more, control users see more content, which violates the assumption that units are independent. That biases the estimate, often towards zero. Mitigations include cluster randomisation, where you assign communities or graph clusters together, and ego-network designs. Separately, you can measure both producer-side and consumer-side effects. Ads have a similar problem through shared budgets and auction competition, which can need budget-split or marketplace-level designs. There's also the novelty effect, so I'd run tests long enough and keep long-term holdouts for big changes. The aim is to know whether a result reflects the true ecosystem effect.

Beyond the primary goal metric, I'd require guardrails in four areas. User-experience negatives: hides, reports, unfollows and survey dissatisfaction. Integrity: prevalence of violating or borderline content, and exposure to misinformation-flagged posts. System health: latency percentiles, error rates, crash rates by app version, and compute cost. Ecosystem: creator reach distribution and ads revenue and advertiser outcomes, since ranking changes shift ad performance. Each guardrail needs a pre-declared threshold, and a breach blocks the ramp regardless of the primary metric. I'd also check that key segments, like specific countries or new users, aren't harmed while the average looks fine.

Work in small diffs on a shared trunk, with mandatory code review and automated tests before landing. Continuous integration runs the tests most relevant to the change, and a broader suite runs before release. Deployment is progressive: internal employees and canary hosts first, then wider tiers, with automated health checks that halt or roll back on regressions. Behaviour changes ship dark behind flags, so deploying code and launching features are decoupled. Bisection tooling identifies which diff caused a regression. The principle is that each change is small, observable and reversible, so speed doesn't mean taking big risks.

First, declare the incident and its severity, so the right people join and there's one incident lead. Mitigate before diagnosing. Check recent deploys, config pushes and flag changes, and roll back or turn off the suspect gate, because that's usually the fastest fix. If it isn't change-related, shed load or switch to degraded ranking to protect availability. Communicate status regularly to stakeholders. Keep a timeline as you go. Once users are safe, find the root cause with traces and metrics by host, region and version. Then write the review, with concrete follow-ups such as better alerts, safer rollout checks or capacity changes.

It focuses on how the system allowed the failure, not on who typed the command. People share the full truth only if they won't be punished for it. A good review has a precise timeline, the user impact, what detected the issue and how long detection took, and the contributing factors across code, tooling, process and alerting. Then it asks why each safeguard didn't catch it. Action items must be specific, owned and tracked to completion, such as adding a pre-deploy check or a kill switch. Otherwise the review is just documentation. Recurring themes across reviews should feed half-year planning, so reliability work gets real priority.

Collect only what has a clear purpose and document that purpose. Respect user settings at serving time. For example, ad preferences and off-platform activity controls should be applied in the ads retrieval path, not only in reporting. Use pseudonymous identifiers in training data where possible, and restrict raw logs with role-based access, audit trails and retention limits. Run privacy review for new data uses, and enforce data-use rules in code where possible, so data tagged for one purpose can't flow into another. Deletion requests must reach derived datasets and feature stores too. Aggregate reporting to advertisers should avoid revealing individuals, for example with minimum audience thresholds.

Ranking rewards engagement, so fake likes, comments and shares directly buy reach. I'd discount engagement from accounts with low trust, such as new, automated-looking or coordinated accounts. Detect coordinated behaviour with graph and timing signals, such as bursts of similar actions from linked accounts. Weight signals that are harder to fake, and cap how much any single cluster can boost a post. Rate-limit actions and add friction at suspicious points. Integrity scores flow into ranking as demotions, and confirmed networks are removed. Keep the exact features confidential and change them regularly, because adversaries adapt. Measure success by how much manipulated content gets reached, not just by account takedowns.

Organic ranking mostly cares about order, so a model that ranks well can still be somewhat miscalibrated. In the ads auction, the estimated action rate is multiplied by the bid to compute value, and charging and pacing depend on it. So absolute values matter. Overestimating for one advertiser wins them auctions they shouldn't win and distorts spend. I'd measure calibration as predicted versus observed rates, overall and by segment, advertiser vertical, placement and new campaigns. I'd apply post-hoc calibration layers and alert on drift. Any new model should launch only after calibration checks, because a small average gain can hide big errors for some advertisers.

Models are behaviour changes even with no code change, so I'd treat them like launches. First, run offline evaluation, including calibration and segment checks. Then shadow-score live traffic without affecting results, to compare predictions and confirm latency and resource use. Next comes a small A/B test, starting with employees, with guardrails on integrity, negative feedback, performance and ads outcomes. Ramp in steps and keep the previous model loaded for instant rollback through a flag. After launch, monitor for drift. Retraining pipelines also need validation gates, so an automatically refreshed model with bad data can't reach full traffic unchecked.

In a past role, a recommendation change raised clicks but slightly increased hides, and both effects were near the edge of significance. Rather than argue opinions, I checked validity first: sample ratio and exposure logging. Then I broke results down by segment and found the hides were concentrated among new users seeing low-quality recommendations. We added a quality threshold for that segment and re-ran the test with a pre-registered success metric and guardrail. The second run improved clicks with neutral hides, so we shipped it. I wrote up the reasoning so the team had a pattern for future ambiguous results, instead of shipping whichever metric looked best.

I'd be explicit that these are illustrative assumptions, not Meta figures. Say there are D daily feed requests, each request retrieves around a thousand candidates, and the heavy model scores a few hundred. Heavy-model inferences per day are roughly D times a few hundred. Multiply that by the cost per inference, which depends on model size and batching, to get the accelerator-seconds needed. Then divide by per-device throughput and add headroom for peaks and failover. The useful conclusion is structural. Heavy-stage compute dominates, so shrinking the candidate count, batching inference and caching user embeddings between requests give the biggest savings. Pagination also helps, because later pages can reuse earlier candidate sets.

The blender receives a ranked organic list and a set of auction-winning ads with their values. It fills slots subject to constraints: minimum spacing between ads, ad-load limits, no repeated advertiser too close together, and diversity rules for organic content, such as not stacking posts from the same author. Conceptually, an ad gets a slot when its value beats the expected cost of displacing the organic post there, including the effect on user experience. Ad load is a long-term trade-off, because more ads raise short-term revenue but can reduce engagement over time. So ad-load changes are tested with long-running holdouts rather than short A/B tests.

Models trained on their own logged outcomes only learn about items they chose to show. That creates popularity bias and position bias. Mitigations start with controlled exploration: a small share of slots goes to candidates the model is less sure about, with the traffic labelled so it can be analysed. Position bias can be corrected by modelling position as a feature during training and fixing it at serving, or by using inverse propensity weighting. Diversity constraints help newer creators and topics get exposure. I'd also keep small long-term holdouts and use survey signals, because engagement logs alone can't tell you whether the loop is drifting somewhere users don't want.

Every flag gets an owner, a purpose and an expected removal date when it's created. Tooling should flag stale gates that have been fully on or fully off for a long time and open cleanup tasks automatically. Long-lived configuration, such as kill switches or regional rules, should be explicitly categorised so it isn't confused with temporary launch gates. Code review should check that both paths are tested while a flag exists. I'd also limit how flags nest, because combinations of flags are hard to reason about. Finally, flag changes are production changes. They need audit logs, review for risky gates, and the ability to roll back quickly.

For a new user, there's little history, so start with signals we have: people they connect with in onboarding, broad locale-appropriate popular content that has passed integrity checks, and fast learning from their first interactions. Session-level features adapt quickly here. For a new post, there's no engagement yet, so use content understanding such as text, image and video embeddings, plus the author's history and the early reactions of a small exposed audience. Controlled exploration gives new posts a fair initial chance. Integrity scoring must complete before wide distribution, because new content from unknown sources carries the most risk.

I treat reliability as part of the plan, not an interruption to it. When setting half-year goals, I'd reserve capacity for on-call, incident follow-ups and maintenance, based on recent history rather than optimism. Then I'd track interrupt load during the half. If incidents keep exceeding that budget, it's a signal to raise reliability work's priority, such as better alerts, automation or removing a fragile dependency, and to say openly which feature goals will slip. I'd keep goals few and measurable so trade-offs are visible. At the mid-point review, I'd adjust based on data. That avoids heroics, where people deliver features while quietly burning out on call.

1. AHeavy models cannot predict likes
2. BTo reduce compute and latency by scoring fewer candidates with the expensive modelCorrect answer
3. CRegulations require several models
4. DCheap models are always more accurate

Why: Early stages prune thousands of candidates so the expensive model runs only on a short list within the latency budget.

1. AEmployees, then small percentages of users, then wider rampsCorrect answer
2. BA single country fully, then employees
3. CAdvertisers only, then everyone
4. DAll users first, then employees

Why: Rollouts start internally, then expand through small A/B test percentages while teams watch metrics.

1. ADelete the database table
2. BWrite a new feature
3. CTurn off the gate for affected usersCorrect answer
4. DWait for the next weekly release

Why: Flags decouple launch from deploy, so disabling the gate reverts behaviour without shipping code.

1. ARestart every server at once
2. BReturn errors for all requests
3. CShed optional work and fall back to simpler ranking while still applying integrity filtersCorrect answer
4. DDisable integrity checks to save compute

Why: Graceful degradation keeps feeds available and safe by dropping non-essential stages first.

1. AFan-out on read, pulling their posts when followers load the feedCorrect answer
2. BStoring the feed only on the client
3. CRebuilding all feeds nightly in batch
4. DFan-out on write to every follower's inbox

Why: Pulling high-follower accounts' posts at read time avoids writing one post into millions of inboxes; many systems use a hybrid of push for normal users and pull for celebrities.

1. AAds rotate randomly among bidders
2. BThe highest bid always wins
3. CThe ad with highest total value: bid times estimated action rate plus ad qualityCorrect answer
4. DThe newest ad wins

Why: Meta publicly explains that total value combines advertiser bid, estimated action rate and ad quality, so relevance and quality matter, not only price.

1. AObjects and associationsCorrect answer
2. BDocuments and collections
3. CKeys and blobs
4. DTables and joins

Why: TAO models the social graph as typed objects (nodes) connected by typed associations (edges).

1. ADemoted to reduce its distributionCorrect answer
2. BShown only to the author's employer
3. CAlways removed
4. DRanked higher to drive engagement

Why: Integrity systems remove violating content but demote borderline or low-quality posts.

1. AIdentify who to discipline
2. BUnderstand systemic causes and fix them without fear of punishmentCorrect answer
3. CAvoid documenting incidents
4. DDelay fixes until next half

Why: Blameless reviews encourage honest accounts so teams can fix the system's weak points.

1. ANetwork interference between test groupsCorrect answer
2. BTraining-serving skew
3. CCache stampede
4. DSample ratio mismatch

Why: Social interactions let treatment effects spill into the control group, violating the independence assumption.

1. ACalibration reduces image sizes
2. BAdvertisers set them manually
3. CThey are only used for logging
4. DTheir absolute values feed auction value and pricing, not just orderingCorrect answer

Why: Auction value combines bid with estimated action rate, so miscalibration distorts winners and spend.

1. AUse unique impression ids and idempotent, deduplicating consumersCorrect answer
2. BDisable retries entirely
3. CCount only on weekends
4. DIgnore duplicates

Why: At-least-once delivery needs idempotency keys so duplicates don't inflate counts or billing.

1. ASlow code review
2. BDifferent model sizes in two regions
3. CA mismatch between features or data seen in training and those at serving timeCorrect answer
4. DUneven GPU temperatures

Why: Skew arises when offline and online features differ, degrading live model quality.

1. AA synonym for revenue
2. BThe metric the change is designed to improve
3. CA metric that must not regress beyond a threshold, even if the primary metric improvesCorrect answer
4. DA metric that is never reported

Why: Guardrails such as hides, integrity prevalence and latency block launches that cause harm elsewhere.

1. ATo avoid any data retention
2. BStreaming is required for code review
3. CTo refresh features and models quickly as behaviour and content changeCorrect answer
4. DBatches cannot store clicks

Why: Fresh features and frequent retraining keep ranking and ads models current.

1. ANovelty effect
2. BPerfect randomisation
3. CA real treatment win
4. DSample ratio mismatch from an assignment or logging bugCorrect answer

Why: An unexpected split signals broken assignment or exposure logging, which invalidates results.

1. AShowing ads only at midnight
2. BA global lock checked synchronously on every auction
3. CPacing controllers that set spend rates, with asynchronous spend reporting and reconciliationCorrect answer
4. DAdvertisers stop campaigns manually

Why: Pacing avoids a slow global counter while smoothing delivery, and reconciliation handles small overspend.

1. ALog everything forever
2. BData minimisation with purpose limits, access controls and retention limitsCorrect answer
3. CShare raw logs with all engineers
4. DStore logs only on client devices without any controls

Why: Collecting only what's needed, restricting access and expiring data reduce exposure and misuse.

1. AEven a tiny false positive rate wrongly removes a large absolute number of legitimate postsCorrect answer
2. BPrecision is cheaper to compute
3. CRemoval is never reversible
4. DRecall doesn't matter at all

Why: Huge volumes turn small error rates into many wrong removals, so low-confidence cases go to demotion or review.

1. AIt encrypts user data
2. BIt makes code compile faster
3. CIt removes the need for code review
4. DIt separates deploying code from exposing behaviour, allowing gradual rollout and instant turn-offCorrect answer

Why: Flags let teams deploy continuously while controlling exposure by audience or percentage, and disable a bad feature without redeploying.

1. AA single-node graph database
2. BAn in-memory store with no persistent backing
3. CA columnar data warehouse
4. DA graph-aware caching tier in front of sharded MySQLCorrect answer

Why: The TAO paper describes a geographically distributed cache layer over sharded MySQL, optimised for read-heavy graph queries.

1. ACluster randomisation of connected usersCorrect answer
2. BRun tests for one minute only
3. CRemove the control group
4. DRandomise by request instead of by user

Why: Assigning graph clusters together keeps most interactions within one arm.

1. ATrain only on synthetic data
2. BUse separate feature definitions for online and offline
3. CRecompute features months later for training
4. DLog the feature values used at serving time and train on themCorrect answer

Why: Logging served features ensures training uses exactly what the model saw at request time.

1. ASelection of features
2. BConfirmation bias
3. CSurvivorship bias
4. DPosition biasCorrect answer

Why: Position bias inflates engagement for higher slots and must be corrected when training on logs.

1. ATo learn about items the model rarely shows and counter feedback loopsCorrect answer
2. BTo hide ads
3. CTo skip integrity checks
4. DTo lower server costs

Why: Models trained on their own outputs lack data on unshown items, and exploration fills that gap.

1. ASort strictly by post id
2. BPut all ads at the bottom
3. CShow only video posts
4. DAvoid placing many posts from the same author consecutivelyCorrect answer

Why: Diversity rules prevent repetitive feeds dominated by one source.

1. AHow often an advertiser may change bids
2. BHow many times a person sees the same ad or advertiser in a periodCorrect answer
3. CThe total number of advertisers
4. DThe image resolution of ads

Why: Frequency caps limit repeated exposure, protecting user experience and ad effectiveness.

1. ASample ratio mismatch
2. BCache invalidation
3. CClock skew
4. DNovelty effectCorrect answer

Why: Users react to something new temporarily, so short tests can overstate long-term impact.

1. AIt inflates false positive ratesCorrect answer
2. BIt reduces sample size
3. CIt breaks feature flags
4. DIt makes tests slower

Why: Multiple looks without correction raise the chance of declaring a spurious win.

1. AShorter code reviews
2. BRequest coalescing so one fetch fills the cache for all waitersCorrect answer
3. CRemoving the cache
4. DIncreasing log verbosity

Why: Coalescing or lease mechanisms stop a thundering herd from overwhelming the backing store.

1. AOnly by its post id
2. BBy advertiser bid
3. CIt cannot be shown at all
4. DUsing content embeddings, author history and limited exploratory exposureCorrect answer

Why: Content and author features plus controlled early exposure address cold start.

1. ACode review
2. BDatabase sharding
3. CFinal billing
4. DCandidate retrieval via user and item embeddings with approximate nearest-neighbour searchCorrect answer

Why: Separate user and item encoders produce embeddings, which allow fast similarity retrieval from large inventories.

1. ANo version control
2. BManual FTP deploys
3. CLong-lived feature branches merged quarterly
4. DTrunk-based development with small, reviewed diffsCorrect answer

Why: Small changes on a shared trunk, hidden behind flags, keep integration continuous and rollbacks easy.