Part 6 · 2 chapters · ~12 min
Feature Flags
Release, experiment, operational and permission flags, local evaluation and streaming updates, targeting, segments and stable percentage rollouts, kill switches, OpenFeature as a vendor-neutral API, LaunchDarkly, Unleash and flagd, testing flagged code, and flag debt with owners and expiry dates.
10
Kinds of flags and how they are evaluated
| kind | lifetime | example |
|---|---|---|
| release | days to weeks | new transfer review screen, rolled out 1% → 100% |
| experiment | weeks | two onboarding flows, measured |
| operational (kill switch) | permanent | disable an expensive recommendation call under load |
| permission / entitlement | permanent | premium features per plan or per country |
HOW A FLAG IS EVALUATED
rules evaluated locally against a context, with a safe default when anything fails
swipe the figure sideways, or tap expand for full screen
1/6
context
The app builds an evaluation context: user id, country, app version, plan, anything targeting may use.
who and what is askingkeep PII out of it where possible
11
OpenFeature, testing and flag debt
code
// OpenFeature: vendor-neutral flag API
import { OpenFeature } from '@openfeature/server-sdk';
OpenFeature.setProvider(new UnleashProvider({ url, appName: 'ledger' })); // or LaunchDarkly, flagd, ...
const flags = OpenFeature.getClient();
const limit = await flags.getNumberValue('daily-transfer-limit-kobo', 20_000_000, { targetingKey: userId, country });
if (await flags.getBooleanValue('new-review-screen', false, { targetingKey: userId })) { ... }flag hygiene
- Every flag has an owner, a kind and an expiry date at creation.
- Release flags are removed from code after full rollout; a lint or a bot opens the removal PR.
- Tests cover both sides of every live flag, plus the default when the provider is down.
- Never nest flags deeply; two interacting flags make four code paths to test.
- Flag changes in production are audited and reviewed for money-affecting flags (part 7).