What are Feature Flags? Why Use Feature Flags?
January 20, 2025
What if I told you that one of the most catastrophic failures in internet history was caused by a simple typo? In 2017, an AWS engineer mistyped a command during routine S3 maintenance, bringing down countless websites and costing over $150 million. S3 powers millions of applications worldwide, so when it fails, the internet feels it.
You might wonder: how could such a small mistake cause such massive damage? The answer reveals a fundamental challenge in software engineering - how do we deploy changes safely at scale?
AWS's post-incident analysis identified three critical gaps that could have prevented this disaster:
- Input validation was missing (the typo should have been caught)
- Configuration changes pushed everywhere at once (no gradual rollout)
- Rollback wasn't automated (manual recovery took too long)
Think about each of these failures for a moment. What if the typo had been caught by input validation? What if the change had been rolled out to just 1% of users first? What if the system could automatically detect problems and roll back? The impact would have been minimal instead of catastrophic.
This brings us to an essential question: how can we avoid the "all-or-nothing" deployment approach that made the S3 incident so damaging? The answer lies in a technique called feature flags.
Understanding Feature Flags Through a Practical Example
Let's start with a concrete scenario. Imagine you're working on a restaurant review app and your team wants to add an AI chatbot that answers questions like "What are the best ramen shops in Tokyo?" You're excited about this feature, but you're also concerned - what if the AI gives wrong recommendations and users lose trust in your app?
Here's where most teams face a dilemma. The traditional approach would be to thoroughly test the feature, then deploy it to all users at once. But what happens if you missed an edge case? What if the AI behaves differently under real-world load than in your test environment?
Feature flags offer a different path. They let you deploy your code to production but control who actually sees the new functionality. Think of it as having a light switch for your features - you can turn them on for some users and off for others, all without changing your code.
Here's what this looks like in practice:
if (user.shouldSee("aiChatbot")) {
showAIChatbot();
} else {
showOldFeature();
}
Notice something important here - user.shouldSee("aiChatbot") doesn't return a hardcoded true or false. Instead, it checks a configuration that you can change through a management platform like LaunchDarkly, PostHog, or AWS AppConfig. This means you can control who sees what without touching your code.
When the feature flag configuration has the AI chat feature turned off, users entering the website won't see the AI chat functionality:
+----------------------------------------+
| Cloud |
| |
| +----------------------------+ |
| | Feature Flag Service | |
| | +----------------------+ | |
| | | Configuration | | |
| | | AI Chat: OFF | | |
| | +----------------------+ | |
| +----------------------------+ |
| ^ | |
| | v |
| 2. Check config | |
| | |
| 3. Return result |
+----------------------------------------+
^ |
| v
1. User enters 4. AI chat feature
webpage not displayed
However, you can enable the AI chat feature in the configuration for specific users, so these users will see it:
+----------------------------------------+
| Cloud |
| |
| +----------------------------+ |
| | Feature Flag Service | |
| | +----------------------+ | |
| | | Configuration | | |
| | | AI Chat: ON | | |
| | +----------------------+ | |
| +----------------------------+ |
| ^ | |
| | v |
| 2. Check config | |
| | |
| 3. Return result |
+----------------------------------------+
^ |
| v
1. User enters 4. AI chat feature
webpage displayed
Why is this separation between code and configuration so powerful? Consider the alternative - if you hardcoded feature availability in your application, you'd need to redeploy every time you wanted to change who could access a feature. With feature flags, you can make these changes instantly through a web interface.
The Mechanics of Gradual Rollouts
Now that you understand the basic concept, let's explore how feature flags enable safer deployments. When your AI chatbot feature is ready, you don't immediately show it to all users. Instead, you start small and expand gradually.
First, you might enable the feature only for your internal team - developers, product managers, and QA testers. This gives you real production testing without any risk to actual users. Your code is running in the live environment, handling real data and traffic, but only your team sees it.
After internal validation, you begin expanding to real users. A typical progression might look like this: 5% of users, then 10%, 30%, 50%, and finally 100%. At each stage, you monitor key metrics like error rates, response times, and user engagement.
But here's the critical question: what happens when you discover a problem? Let's say at the 10% stage, you notice that users with the AI chatbot enabled are leaving your app more frequently than usual. With traditional deployments, you'd need to fix the issue, test it, and redeploy - a process that could take hours or days while the problem affects users.
With feature flags, you can turn off the problematic feature immediately. No code changes, no deployments, no waiting. You flip a switch, and the 10% of users experiencing the problem are instantly protected while you investigate and fix the issue.
This approach dramatically reduces what engineers call the "blast radius" - the scope of users affected when something goes wrong. Instead of everyone experiencing problems, only the small percentage currently included in your test group encounters issues.
This gradual rollout strategy is commonly known as "canary deployment" in the software industry, named after an old mining practice that we'll explore next.
Why "Canary" Deployment?
You might be wondering where the term "canary deployment" comes from. The name references an old mining practice where miners brought canary birds into coal mines to detect toxic gases. Canaries are more sensitive to dangerous gases than humans, so if a canary showed signs of distress or died, miners knew to evacuate immediately.
In software deployment, your initial user group serves as the canary. They experience new features first, and their experience tells you whether it's safe to proceed. If problems arise, you can halt the rollout before affecting your entire user base.
This is quite different from older deployment strategies like blue-green deployment, where teams maintained two identical production environments and switched all traffic at once after testing. While simpler to implement, blue-green deployment lacks the flexibility and risk reduction that comes from gradual exposure.
Common Implementation Patterns
Modern feature flag platforms provide sophisticated targeting capabilities beyond simple percentage-based rollouts. You can create rules like "show AI chat to premium users in North America" or "enable new checkout flow for mobile app users who signed up after January 1st."
These platforms also offer real-time monitoring dashboards that track how your rollouts perform. You can observe conversion rates, error rates, and user behavior across different segments. If metrics deteriorate for users with the new feature enabled, you can react immediately.
The configuration management happens outside your application code, enabling much faster responses than traditional deployment pipelines. Instead of going through the usual build-test-deploy cycle, you can adjust feature exposure through a web interface in seconds.
Consider the broader implications here. Feature flags transform deployment from a binary decision (all users get the change or none do) into a continuous process where you can fine-tune exposure based on real user feedback and system performance.
This flexibility makes feature flags valuable beyond just risk management. Teams use them for A/B testing different user interface designs, gradually migrating users from old systems to new ones, and creating emergency kill switches when critical issues arise in production.
As an engineer, you'll likely encounter feature flags in most modern software organizations. Understanding how to implement and manage them effectively will make you a more valuable team member and help you think more strategically about deployment risk.
The next time you're working on a significant feature, ask yourself: how can I reduce the risk of this change? How can I get real user feedback before committing fully? Feature flags provide the tools to answer these questions confidently.
Support ExplainThis
If you found this content helpful, please consider supporting our work with a one-time donation of whatever amount feels right to you through this Buy Me a Coffee page, or share the article with your friends to help us reach more readers.
Creating in-depth technical content takes significant time. Your support helps us continue producing high-quality educational content accessible to everyone.