You ship a feature. Three minutes later, on-call pings you: error rate spiked. You need to roll back. A full redeploy takes 20 minutes. With a feature flag, rollback takes 30 seconds.

What a Flag Is#

A feature flag is a conditional in your code. If the flag is on, the new code path runs. If it’s off, the old behavior runs. The flag is a config value read at runtime, not at deploy time. Changing a flag doesn’t require a deploy.

This separates deployment from release. You deploy code with the flag off. The feature is dark. You test it internally. You roll it out to 10% of users. If something breaks, you flip the flag. No code changes. No redeploy.

Consistent Rollout#

Flags can target specific users, percentages, or attribute-based rules. Consistent per-user rollout matters: a user should see the same experience across requests, not a random coin flip each time.

The consistent part comes from hashing. Hash the user ID against the flag name. The hash value puts the user in a bucket. If the bucket falls within the rollout percentage, the flag is on for that user. Same user, same hash, same result every time.

graph TD A[Request with user ID] --> B[Flag Service: check targeting rules] B --> C[Flag config from Redis cache] C --> B B --> D{Hash user ID into bucket} D -->|Bucket in rollout range| E[New code path] D -->|Bucket outside rollout| F[Old code path] style A fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff style B fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff style C fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff style D fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff style E fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff style F fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff

Kill Switches#

The emergency case is a kill switch. Not a rollout, just on/off. When a service is overloaded or a new code path has a critical bug, you flip the switch and the feature goes dark immediately for everyone. Kill switches need to be read from a fast in-memory cache, not a database. The evaluation needs to happen in under a millisecond.

At Salesforce#

We shipped a new email tracking feature to our CRM and released it to 100% of users in one deploy. Within an hour, the email service was overwhelmed. We had no kill switch. The rollback was a full redeploy that took 35 minutes. After that, we never shipped a significant feature without a flag. The discipline of always having a rollback path changed how the team thought about releases.

What I’m Learning#

Flag debt is real. After six months you have 40 flags and nobody knows which are still active or which old code paths can be deleted. Flags need expiry dates and owners, the same as any other config.

What’s your process for cleaning up old feature flags, and has accumulated flag debt ever bitten you?