Feature Flag

If a feature flag makes a network request during the initialization phase, it adds network round-trip time to the cold start, amplifying tail latency.

"Bundling the data file with the deployment + carrying the revision number on invocation" is a hybrid approach that retains the low latency of local reads while verifying data freshness across the invocation path via the revision number.

A feature flag is an engineering practice that decouples feature release from code deployment: switch checks are embedded in the code in advance, and the configuration center dynamically determines which users and which environments a feature takes effect for.

Using feature flags' percentage rollout directly to run experiments makes it easy to encounter problems such as non-random traffic splitting, imbalanced sample proportions, and the same user being assigned to different groups on different devices.

Feature flags and A/B testing share the "grouping + traffic splitting" capability in engineering implementation, but their goals differ: flags focus on release control, while experiments focus on causal inference.

The value of Flagsmith Experiments lies in reusing the existing grouping identifiers of flags as experiment units and supplementing them with a randomization and statistics layer.

On LaunchDarkly, anonymous visitors push up client-side monthly active context costs, reaching about $1,020/month at 100k MAU.

Local Evaluation mode uses a server-side SDK to periodically pull the full rule set and evaluate it in memory, communicating with the platform only when rules change, thereby shifting the billing unit from "per evaluation" to "per rule sync".

Feature flag platforms typically bill by "context", i.e. each evaluated user or device identifier counts as one metering unit. Because anonymous visitors have no stable ID, platforms often generate a new context for each session or even each page load, causing MAU counts to be inflated.