Feature Flag Lifecycle

Feature Flag Lifecycle

Overview

Feature flags decouple deployment from release. Code ships dark (behind a flag), then is gradually exposed to increasing percentages of traffic. Every flag has a defined lifecycle: creation → gradual rollout → full rollout → cleanup. Flags that live forever become tech debt that obscures code paths and creates combinatorial testing nightmares. Kill switches provide instant off-switches for new features without requiring deployment.

When to Use

• Launching any customer-facing feature
• Deploying code that changes behavior for existing functionality
• Running A/B tests or experiments
• Providing a kill switch for risky changes
• Migrating between systems (old path vs. new path)
• Enabling features for internal testing before customer exposure

Amazon Context

Amazon treats feature flags as first-class operational controls. A feature without a kill switch is a feature you can't turn off at 3 AM when it's causing problems. The gradual rollout pattern (1% → 5% → 25% → 50% → 100%) is not arbitrary—each stage allows you to detect different classes of problems. 1% catches crashes and obvious errors. 5% catches performance issues. 25% catches capacity problems. 50% catches subtle behavioral differences. Flags that outlive their purpose are aggressively cleaned up because stale flags are a source of both confusion and incidents.

The Process

Flag Creation

1. Name: Descriptive, follows naming convention (e.g., feature.payment.new-checkout-flow)
2. Owner: Individual engineer responsible for the flag's lifecycle
3. Expiration date: When this flag should be removed (max 90 days for launch flags, 30 days for experiments)
4. Type: Launch flag, experiment flag, ops kill switch, or permission gate
5. Default state: Off (new features start dark)
6. Kill switch behavior: What happens when toggled off mid-traffic (graceful degradation, not crash)
7. Metrics: What metrics indicate success/failure at each rollout stage