feature-flags

Use consistent hashing: hash the flag name plus user ID with MD5, take modulo 100, and compare against the rollout percentage. This guarantees the same user always gets the same result as you ramp from 5% to 100%.

There are four types: release toggles (temporary, removed after rollout), experiment flags (A/B tests with variant assignment), ops flags (permanent, like maintenance mode), and permission flags (permanent, gating premium features).

Database-backed flags work for simple needs using a table with enabled, rollout_percentage, and whitelist columns. LaunchDarkly suits larger systems needing managed targeting rules, SDKs, and server-side evaluation with user context attributes.

Create an admin-only endpoint that sets the flag to disabled, resets rollout percentage to zero, clears the cached config, and writes an audit log entry. You can also auto-disable flags when error rates exceed a threshold like 10%.

Release toggles must be removed within 90 days of reaching 100% rollout. Run monthly stale flag detection by grepping the codebase for flag references and comparing against flags stored in the database.

Evaluation must stay under 10ms, so querying the database per request is too slow. Cache flag configurations in memory or Redis and invalidate the cache whenever a flag state changes.