Feature Flag Service with Local Evaluation and Stale Flag Cleanup

The problem: flags that make releases safe, then make code messy

Feature flags let a team merge unfinished work, turn a feature on for staff first, and switch it off in seconds when something breaks. Small teams usually start with an environment variable or a row in a settings table. It works until they need "on for 10 percent of users" or "on for this one client", and until someone has to redeploy just to flip a switch during an incident.

The second problem arrives later. Flags are easy to add and nobody removes them. After a year the code is full of conditionals for features that shipped long ago, and nobody is sure which branches are dead. Uber built a dedicated tool, Piranha, to remove stale flags automatically because the clean-up cost had become significant for them.

What already exists and the gap

• LaunchDarkly is the best-known hosted flag platform, full-featured and priced for companies with a budget for it.
• Unleash and Flagsmith are open source flag servers with hosted plans; Flagsmith server SDKs call the API per evaluation unless local evaluation is switched on.
• GrowthBook combines flags with experimentation on top of your data warehouse.
• OpenFeature, a CNCF project, defines a vendor-neutral SDK interface, with flagd as its reference flag daemon.

The gap for a student project is not "another flag server" but a small one designed around two things the free options handle unevenly: fast local evaluation with instant updates, and a built-in answer to flag debt that looks at the code, not just the dashboard.

What you build

• Flag server: projects, environments, flags, variants and targeting rules, stored in PostgreSQL with full version history.
• Admin UI: create and edit flags, see which environments have them on, roll back to an earlier version, view the audit log.
• SDKs: two server-side SDKs (for example Node.js and Python or Go) implementing the OpenFeature provider interface. They fetch the full ruleset on start, keep it in memory, and apply updates pushed over Server-Sent Events.
• Stale flag scanner: a CLI you run in CI that finds flag keys in the code and cross-checks them against the server's rollout state and last-changed date.

The technically interesting part

Two problems carry the grade. First, consistency: bucketing must be deterministic and identical across languages, typically a hash of the flag key and user id mapped to 0 to 99. Different hash libraries, string encodings and integer handling will quietly disagree. A shared file of test vectors that every SDK must pass is how you prove it. Second, propagation: when someone turns a flag off during an incident, every running instance should see it within a couple of seconds, survive a dropped connection by reconnecting and catching up, and keep serving the last known ruleset if the server is down. Show a live demo where you kill the flag server and the app keeps working.

How to evaluate it

• Evaluation latency: microbenchmarks of in-process evaluation against a naive per-request HTTP call.
• Propagation time: timestamp a change on the server and on 20 or more SDK instances; report median and worst case.
• Correctness: cross-SDK bucketing agreement on at least 100,000 generated users, and a percentage rollout that lands within a tight tolerance of its target.
• Scanner precision: run it on two or three open source repositories that use flags, and hand-check its stale candidates.
• Resilience: behaviour when the server restarts, when the network drops, and when the ruleset is malformed.

Suggested plan

1. Semester 1, weeks 1 to 5: data model, flag server API, admin UI basics and audit log.
2. Weeks 6 to 10: first SDK with local evaluation, test vectors and streaming updates.
3. Weeks 11 to 14: second SDK, resilience tests and a mid-project demo.
4. Semester 2, weeks 1 to 5: stale flag scanner with tree-sitter for two languages.
5. Weeks 6 to 10: benchmarks, propagation study and a pilot with one real team.
6. Weeks 11 to 14: write-up and polish.

Path to a product

The first customer is a small software house or startup that has outgrown environment variables and does not want another USD subscription. Offer it open source with a paid hosted version priced per project, or sell the stale flag scanner as a separate CI add-on that works with any flag provider, which widens the market. A good pilot is a local product company with frequent releases.

Scope warning

Do not build A/B testing statistics, a client-side JavaScript SDK for browsers and mobile SDKs all at once. Two server SDKs are enough. Do not write your own parser; use tree-sitter. Avoid building user management beyond simple roles.

Learn what you need on Sefism

• System design roadmap : caching, push versus pull and consistency trade-offs behind flag delivery.
• Backend cheat sheet : API and streaming patterns for the flag server.
• GitHub Engineering Blog : how a large engineering team ships changes safely, flags included.
• Software Engineering at Google : the chapters on code health and large-scale changes explain why flag debt matters.
• How to learn system design as a junior developer : a sensible path if distributed systems feel new.

Get help with this idea

Start with the test vectors and the streaming update path; the admin UI can come later. A mentor can help you set the scope, pick a stack you can finish with, and design an evaluation your examiners will respect. The build is yours; the guidance is on scope, stack and evaluation. New here? Create a free account first.

• Discuss this idea with a mentor
• Send a query to Tauseef
• Book a 1:1 session