Objective: Centralized Feature Flag System
This article is not about a basic feature flag stored in a JSON file or a database. It is about a centralized feature-flag system with a dashboard that lets you enable a feature, roll it back instantly, and roll out changes to specific segments just by flipping a few toggles. That kind of control is a real luxury, and it is something QA, business stakeholders, and developers can all take advantage of.
R&D Phase
You might wonder why I didn’t just maintain flags in a database, JSON, or environment variables. The table below summarizes why those options fall short.
| S3 JSON files | Database approach | Environment variables |
|---|---|---|
| ❌ Manual file updates required | ❌ Requires database migrations for each flag | ❌ Requires code deployment for changes |
| ❌ No real-time updates | ❌ Need to manage DB connections | ❌ No dynamic updates |
| ❌ Deployment needed for changes | ❌ Cache invalidation complexity | ❌ Environment-specific complexity |
| ❌ Version control conflicts | ❌ Scaling issues with high traffic | ❌ No user segmentation |
| ❌ No user-targeting capabilities | ❌ No built-in audit trail | ❌ Hard to manage at scale |
| ❌ Risk of stale data | ❌ Risk of configuration drift |
I had multiple options for feature flag management systems, but I chose Flipt.
Why Flipt?
- Provides a centralized dashboard for managing flags
- Supports creating segments and rollouts
- Offers an open-source, self-hosted solution
- Ensures OpenFeature compatibility, which is important for standardization
- Delivers real-time updates
- Includes built-in targeting and segmentation
Planning Phase (Sharpening the Axe)
Use the Flipt SDK directly, or use Flipt + OpenFeature?
I chose Flipt + OpenFeature because OpenFeature is a standard. You can create an OpenFeature instance and use it with any provider. In my case, the provider is Flipt. If I ever switch away from Flipt in the future, I can change the provider without having to touch the application code.
Designing the Axe Handle to Fit Our Product
As I explored Flipt’s architecture, I found two ways to read a feature flag: evaluate it directly from the frontend, or have the backend fetch it and return the result via a REST API. I chose the backend approach because I needed to verify sensitive data before returning the flag result.
However, this raised a crucial question around standardization. We created my our own development standards for feature flags, covering:
- Naming conventions — kebab-case keys with purpose-based prefixes (e.g.,
feature-,release-,ops-,kill-) - Segment architecture — layered segments (global, region, team) with reusable admin/QA whitelists
- Rollout strategy — phased percentage rollouts (canary 5% → early adopters 25% → wider 50% → GA 100%)
- Backend vs. frontend evaluation — backend for sensitive logic and IP-based targeting; frontend for UI-only toggles
- Flag lifecycle — structured creation, rollout, stabilization, and cleanup with expiry guidelines
Tip: If you want to evaluate a flag directly from the frontend, you can create a separate namespace for frontend flags. Then, make an evaluation call to the Flipt server and return the evaluated result.
Architecture Overview:
With the architecture designed, the next challenge was implementation. How do I write clean, maintainable code that follows best practices? This is where Claude Code became my main assistant.
Code Implementation
My first requirement was to disable the new feature-related application across all UI spaces and hide it from the application list, the application detail view screen, and the application creation option.
I am not a backend engineer, but Claude Code became my development partner. I asked it to write backend code using an Aspect-Oriented Programming (AOP) approach so I could keep the codebase clean without introducing noise. On the frontend side, it helped me create a custom hook that follows my team’s standards.
I architected the solution as follows: the frontend makes an API call to the backend, which then performs a boolean evaluation call to retrieve the feature flag from Flipt.
The 404 Mystery
Despite having the correct URL, namespace, and bearer token configured in the Flipt Java SDK, I kept hitting a frustrating 404 error.
To debug this, I took a comprehensive approach and added all relevant repositories to Claude’s context:
- Flipt management repo
- Kubernetes manifest repo
- Service Terraform repo
- Backend repo
- Frontend repo
I then asked Claude: “These are the service folders for my product. Picture the network flow and identify the problem.”
Claude traced through the entire infrastructure and discovered the root cause: the evaluation endpoint was missing from the Flipt ingress configuration. Additionally, it provided the exact Kubernetes manifest change needed to fix it.
The Flipt team addressed the issue within 2 hours. After verification, I deployed to staging, and everything worked flawlessly.
Impact & Results
Before:
- Manual flag management
- Deployment required for changes
- No targeting capabilities
- High maintenance overhead
After:
- ✅ Real-time flag updates
- ✅ No deployment needed
- ✅ User targeting support
- ✅ Reduced maintenance
- ✅ Better developer experience
Acknowledgments:
A huge thank you to the Flipt team for their incredibly quick response and support in resolving the ingress configuration issue. Their expertise and responsiveness made this implementation journey smooth and successful.
Thanks for reading. I hope this article helps you implement a similar feature flag system in your product. If you have questions or want to learn more, feel free to ping me on Slack.
— Selva, Team Lead MF India (MFX Banking Service Development Group)