It was supposed to be just another simple release.
The team had rewritten a critical feature — everything tested, validated, looking clean. Deployment done, everything live. But all it took was an unexpected behavior with a specific group of users… and that was it: operations stalled, incidents started popping up everywhere, and the rollback turned into a race against time.
How many times have you seen this happen? Honestly, I’ve lost count. Sometimes as a spectator, other times right there in the middle of it — running along, trying to fix things in the heat of the moment.
But let me ask you this: what if there was a simpler way to roll things back? No need to run a new pipeline, no need to touch manifests, no need to trigger a new deployment. Just… turn off V2 and go back to V1. That simple.
And the truth is, there is something that helps minimize all of this: Feature Flags — one of those ideas that, once you understand and start using, you wonder how you ever lived without.
This isn’t about making your system more complex. It’s about gaining control, flexibility, and safety when dealing with changes — especially in environments where moving fast is essential, but mistakes are costly.
What is a Feature Flag?
In simple terms: it’s a flag, a switch that you turn on or off to enable or disable specific features in your system. It can be a true/false, a percentage rollout, user segmentation, and so on.
Here’s the magic: you keep two versions of a logic in your code, but only one is active. And you can switch between them without deploying.
Why is this so important?
Because in a modern architecture — or better yet, in any architecture that wants to evolve safely — you need tools that let you deliver without fear. With Feature Flags, you can:
- Reduce risk in releases
- Enable or disable features without downtime
- Roll back in seconds, without redeploying
- Refactor with confidence, without risking the entire system
- Operate with much more control and flexibility
- Gradually release new features to a subset of users in a safe way
And all of this without slowing down the team, without relying on new deployments, and without those last-minute headaches.
A real-world example
Imagine you rewrote your invoice generation logic and packaged everything into your application’s V2 version. Instead of pushing it straight to production and crossing your fingers, you deploy as usual — but keep the new feature disabled by default, controlled by a feature flag.
At any moment, you can enable the flag for a specific group of users, observe behavior, monitor logs… and if something goes wrong? Simple: turn the flag off and everything goes back to how it was. No redeploy. No rollback. No panic.
(And this makes even more sense when we talk about refactoring with the strangler fig pattern! But that’s a topic for another newsletter 😉)
Feature Flags in real operations
They’re not just for releases. Feature Flags shine in day-to-day operations too:
- Enable or disable routes using environment variables
- Allow targeted debugging with specific flags
- Help isolate failures without touching the code
- Avoid commented, conditional, or hardcoded logic
- Can be applied per user, group, region, or even time
And the best part: you can implement this in many ways — from simple to highly robust — using local files, environment variables, configuration databases, or tools like AWS AppConfig, LaunchDarkly, Unleash, Flagsmith, ConfigCat…
Each comes with different levels of control, integration, and governance. The right choice depends on your context — what matters is having this capability in your hands.
And of course, you can build a lot of this yourself without relying on market tools…
Push vs Pull
A well-implemented flag isn’t push-based — it’s pull-based. That means your application periodically checks the flag value — from a file, an API, or an environment variable — and acts based on that value.
This gives you control, safety, and independence. No more being stuck in deployment cycles just to change an if.
Conclusion
Architecture is not about following trends — it’s about having control, confidence, and
Architecture isn’t about following trends — it’s about control, confidence, and adaptability.
Feature Flags give you that: the ability to evolve without blocking deliveries, avoid risky rollbacks, and operate with real control over change.
More than a technique, they become part of how you design and run modern systems.
And from an SRE perspective, this is gold: mitigate incidents in seconds, reduce blast radius, and react without depending on deployments.
Cheers,
Douglas Mugnos
MUGNOS-IT 🚀
