Feature Flags
Feature flags are runtime configuration values that enable or disable features without a code deployment. They allow decoupling feature release from code deployment.
Feature flags = light switches on a wall. Each switch controls a different room's lights — flip one on for beta testers, keep others off, and if something catches fire, kill the switch instantly without rewiring the house.
Feature flags serve multiple purposes: (1) trunk-based development — merge incomplete features behind a flag to avoid long-lived branches; (2) gradual rollout — enable for 1% of users, ramp to 100%; (3) A/B testing — expose different variants to different user segments; (4) operational kill switches — instantly disable a feature causing production incidents without rolling back a deployment. Managed feature flag services (LaunchDarkly, Split.io, AWS Evidently) provide SDKs with local flag evaluation (no latency overhead), rule-based targeting (user ID, country, plan tier), and audit logs.
Feature flag technical debt is a real risk. Flags that are not removed after full rollout accumulate: conditional logic branches, test matrix complexity, and cognitive load. Enforce a policy: every flag has a removal date set at creation; flags older than 90 days without a removal ticket trigger an alert. Flag evaluation must be cached locally — evaluating a flag via an HTTP call on every request adds unacceptable latency. SDK-level flag state is streamed from the flag service and evaluated in-memory (<1ms). Database feature flags (storing flag values in a DB row) are an anti-pattern — you've just traded a slow config mechanism for a DB dependency.
I use feature flags as the primary mechanism for both continuous delivery and operational safety. Every new user-facing feature ships behind a flag, enabling us to deploy code daily while controlling the release schedule independently. Flags are defined in LaunchDarkly with: targeting rules (user ID or percentage rollout), a kill switch (override to off for all users), and a removal date. The removal date is enforced by a bot that creates Jira tickets 2 weeks before expiry.
Using feature flags for configuration management (database URLs, timeouts, secret keys). Feature flags are for feature gating, not configuration. Configuration belongs in environment variables or a secrets manager with proper access control.