Comment by bluelightning2k

The flags (whether they be booleans, strings, numbers, or anything else) are the trivial part. It's the targeting and rollout rules (i.e. who gets to see which flags), and the requirements for extremely fast and consistent evaluation of these rules, that can get surprisingly complicated fast, and folks who have rolled their own usually find that product management or marketing or sales wants to target using more complex rules, and the problem balloons.

I agree that problem is not particularly hard in the grand scheme of things, but it is actually quite big, meaning it requires a lot of features that aren't obvious at first glance.

Edit: Thought of another analogy that may help explain the complexity. At their heart, feature flags are really a permissioning system: only certain users get access to certain pieces of functionality. Anyone who has ever dealt with permission systems know how complex they can be: group membership, including hierarchical groups, roles, ACLs, etc. All of those things are really analogous (actually, a subset really) to the various types of targeting rules that can be used in a feature flags system.

Percentage rollouts, RBAC, audit history, A/B testing, multivariate - it gets complex quick. That boolean turns into a whole system you have to maintain and operate.

Here's one detailed blog about it: https://martinfowler.com/articles/feature-toggles.html

They're not always booleans - for example, we often see feature flags being used for A/B rollouts.

Cloudflare themselves even uses them internally as such, by shipping new features/builds to their free customers first, and then progressively larger customers after a settling period.

Feature flags can also be randomly turned on, for a sort of fuzz testing. Don't think of them just as 'new things' - it could be 'changed behavior'.

I guess you could think of them as a boolean on every client but they're generally not implemented that way.

This is just an implementation detail, a feature flag can very well be implemented with a Boolean in a database.

To me the main appeal of feature flags is that they allow to work on large features that often require months and many commits to finish in a main branch. This, at least to me, results in a more lightweight and more iterative development process. This contrasts with maintaining a separate branch, with perhaps separate deployment target for a large in-development features.

efficient delivery of the single bit (and especially the flip event) to the desired audience is the use case. the actual payload almost doesn't matter as long as it's reasonably small.

These are booleans with a bit more context. They may only apply to a particular geographic area, and may have dependencies: if we turn off flag X, we automatically turn off flag Y.

It's the tooling around them.

How do you set a boolean to only return true for queries to 5% of the fleet? And which 5% of the fleet? And then ramp up on a predefined cadence? Or how about returning true only for customers in the preview group for the feature? Does the database return false automatically if the 5% of the fleet where it's true start crashing or throwing exceptions? Does it hook into your observability stack?

Fundamentally, sure, you could just implement it as a boolean in the database. It's the integration and tooling that works with the rest of your stack that makes it worthy of the name "feature flag".

That’s all it is. This only exists to lock you into cloudflare even more.