A typical mid-stage codebase has 200 feature flags. About 30 of them are on for everyone and could have been deleted a year ago. Twenty are off for everyone and exist only because the engineer who shipped the kill switch left the company. Forty are scoped to “internal users” but the internal-users group has not been updated since the company’s first office. The rest are doing real work, but you cannot tell which is which without reading every check site.
This is what flag debt looks like. The cure is not “use feature flags less.” Feature flags are one of the highest-leverage techniques in modern delivery. The cure is treating the four kinds of flags as four different things, because they have different lifetimes, owners, and cleanup rules.
Release toggles. Short-lived. Wraps a half-built feature so the unfinished code can ship to production behind an off switch. The flag exists to decouple deploy from launch. Once the feature launches and survives a week, the flag is deleted. Lifetime: days to weeks. Owner: the engineer shipping the feature.
Operational toggles. Long-lived. A kill switch you flip in an incident: “disable the new pricing API,” “fall back to the v1 search backend.” Designed to live in the codebase indefinitely as a safety mechanism. Lifetime: as long as the feature exists. Owner: the on-call rotation.
Permission toggles. Long-lived. Controls who sees a feature: free vs paid, beta-tester opt-in, region-specific. Functionally identical to a permission system, often (sloppily) implemented as a flag. Lifetime: as long as the segmentation exists. Owner: product / billing team.
Experiments. Short-lived. A/B tests where the goal is to ship one of the variants and delete the other. Lifetime: hours (a hotfix experiment) to weeks (a proper test). Owner: the experiment owner, typically PM + engineer.
The four kinds need different infrastructure decisions. Release toggles want fast evaluation and don’t need analytics. Operational toggles want low-latency global flips and audit logs. Permission toggles want segmentation by user attributes. Experiments want event tracking and statistical evaluation. One LaunchDarkly account can serve all four, but the processes around each are different.
The single most important rule: every release toggle has a deletion date in the codebase. Not a deletion ticket, not a Notion doc, but a comment in the source.
// FLAG: new-checkout-flow
// Type: release
// Created: 2022-09-12
// Delete by: 2022-10-15 (or sooner if 100% rolled out for a week)
// Owner: @mira
if (flags.isEnabled('new-checkout-flow', user)) {
return renderNewCheckout();
}
return renderOldCheckout();A weekly cron job greps the codebase for these comments, finds expired ones, and opens issues. That is the entire system. The cron does not need to be smart; it just needs to be loud.
#!/usr/bin/env bash
# flag-cleanup.sh - find release flags past their delete-by date.
set -euo pipefail
TODAY=$(date +%Y-%m-%d)
git grep -nE 'Delete by: [0-9]{4}-[0-9]{2}-[0-9]{2}' \
| awk -v today="$TODAY" '
match($0, /Delete by: ([0-9-]+)/, m) {
if (m[1] < today) print
}'Pipe the output to a Slack channel. Two months in, the team has internalized the rhythm: ship a flag, write the comment, delete the flag two weeks later. No flag debt.
A clean release toggle has six steps and lives about two weeks.
Step 6 is the one teams skip. The result is a codebase where every feature has two implementations and the old one is never tested. Discipline around step 6 is what separates teams that ship fast from teams that move fast and break things.
Different rules. Operational toggles do not get deleted; they get audited.
A good operational toggle has:
// FLAG: kill-switch-stripe-webhooks
// Type: operational
// Effect: when ON, webhook delivery to Stripe is paused; events queue in DB.
// Runbook: https://internal/runbooks/stripe-webhooks
// Last flip: 2022-08-14, flipped during Stripe outage, restored same day.
if (flags.isEnabled('kill-switch-stripe-webhooks')) {
await queueEvent(event);
return;
}
await deliverWebhook(event);The runbook link is the difference between a useful kill switch and a tripwire that nobody dares touch. If on-call cannot find the documentation in 30 seconds at 3 a.m., the kill switch is decoration.
If you are using your feature-flag system to express “paid users get this feature,” you are eventually going to regret it. Permissions and flags share an evaluation pattern but diverge sharply on data model.
A permission has:
A flag has none of those; it is a global switch with simple targeting. Implementing permissions as flags works for the first 10 features and breaks at the 50th, when product asks “show me everything Alice can access” and the answer is “grep the code.”
For permission-style decisions, build a thin authorization layer (or use one: Cerbos, Oso, OpenFGA) and reserve the flag system for actual flags. The single place I’ll bend this rule is beta opt-in toggles, where the permission is genuinely “is this user opted into the beta?”, which is shaped enough like a flag to fit.
An A/B test is a flag plus an event-tracking pipeline plus a statistical evaluator. The flag part is the easy part. Most experiment systems make three mistakes:
Sticky assignment is missing or broken. A user who saw the green button on Tuesday and the red one on Thursday is not in the experiment; they are noise. Bucket on user_id (or a stable cookie for logged-out), and write the assignment to a log table the first time you see it. Subsequent reads use that log, not a recomputation.
SRM (sample ratio mismatch) is not checked. If you assign 50/50 and end up with 47/53 split, the experiment has a bug, usually a filter that drops one variant differently. Always run a chi-square check on the assignment ratios; reject the experiment if SRM is off.
Stop conditions are not pre-registered. “Watch the dashboard until it looks good” is not a methodology. Set the sample size, the metrics, and the decision rule before the experiment starts. Otherwise you are running a guided fishing trip.
The flag system supports the experiment, it does not run it. If you do not have an event pipeline that knows the assignment, you are running a feature flag, not an experiment.
For a team under ~20 engineers shipping ~5 flags per quarter, a homegrown system is fine: a config table in your existing database, a simple API to fetch flags by name, in-process caching with a 30-second TTL. About 200 lines of code.
Past that scale, the operational cost of running your own (cache invalidation, audit logs, percentage rollouts that match across services, sticky assignment) starts to exceed the cost of LaunchDarkly / Statsig / Unleash. The break-even is somewhere around 50 flags or 5 simultaneous experiments; at that point, buying gives you the SDKs, the rollout dashboards, and the audit trail for less than what an engineer would charge to maintain the homegrown one.
The mistake is going either direction prematurely. A 5-engineer team buying LaunchDarkly day one is overpaying. A 100-engineer team still on a feature_flags SQL table is paying in incidents.
For the flag system as a whole, a small dashboard answers “is this healthy?”:
The “evaluation error rate” metric saves more incidents than it sounds like. Most flag SDKs default to a fallback value if the flag service is unreachable, and your code probably does not handle “fallback” gracefully, so the new feature just disappears and somebody on Twitter complains before your alerts fire.
Feature flags are a force multiplier when you treat them as four different tools with four different lifetimes. Release toggles get a delete date in the source. Operational toggles get a runbook. Permissions go in the auth system, not the flag system. Experiments need event tracking and pre-registered stop conditions.
The team that gets this right ships continuously and has 30 active flags. The team that gets it wrong has 300, mostly unowned, and does not know which ones are load-bearing. The difference is not the tooling. It is the discipline of treating each kind as the kind of thing it is.
The discipline of “every release toggle gets deleted within two weeks” is the kind of process detail that does not show up in a feature roadmap and decides whether a codebase still ships fast at year three. It is the kind of engineering culture Yojji’s teams build into the products they deliver for clients.
Yojji is an international custom software development company founded in 2016, with teams across Europe, the US, and the UK. They focus on the JavaScript ecosystem (React, Node.js, TypeScript), cloud platforms (AWS, Azure, GCP), and full-cycle product delivery, including the rollout and cleanup processes that decide whether feature flags are an asset or a slow-growing tax.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。