# Wat zijn feature flags? Het deploymentcontract in productie

URL: https://upstreamapi.com/nl/journal/wat-zijn-feature-flags
Type: blog
Locale: nl
Published: 2026-08-29
Updated: 2026-08-31

---

> Feature flags bepalen welke code actief is per gebruiker, zonder nieuwe build. Ze scheiden deployment van release. Dit artikel bespreekt SLO-gated rollouts, kill switch design en flag debt.

Wat zijn feature flags? Het zijn conditionele checks in je applicatiecode die bepalen welke codepaden worden uitgevoerd voor een gegeven gebruiker, sessie of omgeving, zonder een nieuwe build te shippen. Een flag `new_checkout_flow` die op `false` staat voor 99% van je gebruikersbasis betekent dat je die code twee weken geleden al hebt uitgerold. Je hebt hem alleen nog niet ingeschakeld. Het contract dat ze vestigen is precies: deployment en release worden twee aparte gebeurtenissen. Voor elk team dat continuous deployment doet op schaal is dat contract structureel.

## Deployment en release zijn niet hetzelfde moment

De meeste teams leren dit onderscheid na een slechte rollout. Een feature gaat dinsdag live, iets in de request trace gedraagt zich anders tegen woensdagochtend, en tegen de tijd dat iemand een onderzoek opent, beslaat de diff vier commits en twee servicegrenzen. Oorzakelijkheid toewijzen in dat scenario is oprecht moeilijk.

Feature flags dwingen tot precisie. Wanneer de code achter een flag wordt gemerged en gedeployed, ligt hij inert in productie. Je bevestigt dat de deployment is geslaagd, observeert baseline-metrics gedurende een paar uur of dagen, en verifieert dat er niets is gedegradeerd. Dan zet je de flag aan voor 1% van het verkeer. Je hebt nu een enkele toerekenbare variabele. Als de foutrate stijgt op het geflagde pad, debug je geen code-diff. Je schakelt een configuratiewaarde om.

Die scheiding is niet primair een snelheidsargument. Het is een blast-radius-argument. Een release die 1% van de sessies treft en fout gaat, is in minuten te herstellen. Een release die 100% van de sessies treft en fout gaat, is een groot incident.

Het mechanisme zelf is rechttoe rechtaan. In TypeScript ziet een flag-evaluatie er ruwweg zo uit:

`const showNewCheckoutFlow = flagClient.variation(
  'new_checkout_flow',
  { userKey: session.userId, custom: { plan: user.plan } },
  false // standaard als de flag-service onbereikbaar is
);

if (showNewCheckoutFlow) {
  return renderNewFlow(cart);
}
return renderLegacyFlow(cart);`De `false`-standaard is geen formaliteit. Het is het gedrag dat je gebruikers krijgen als de flag-evaluatieservice een netwerkpartitie heeft. Definieer het bewust, niet per ongeluk.

## De vier flagtypes die er daadwerkelijk toe doen in productie

Niet alle feature flags dienen hetzelfde operationele doel. Ze identiek behandelen in je codebase en tooling is een betrouwbaar pad naar verwarring tijdens incidenten en de opbouw van flag debt.

**Release flags** bewaken nieuwe features tijdens ontwikkeling en rollout. Ze zijn bedoeld als tijdelijk: aangemaakt wanneer het werk aan een feature branch begint, verwijderd zodra de feature 100% van de gebruikers heeft bereikt en het team de stabiliteit heeft bevestigd. Release flags zonder verwijderdatum en zonder eigenaar worden permanent meubilair in je codebase.

**Experiment flags** sturen A/B-tests en multivariante experimenten aan. Ze zijn gekoppeld aan analytics-cohort-identificatoren en hun levenscyclus wordt begrensd door het experiment. Wanneer het experiment eindigt, gaat de flag mee. De veelgemaakte fout: de winnende variant achter de flag houden, omdat verwijdering "niet urgent" is. Twee jaar later is de experiment-flag onderdeel van het kritieke pad en niemand weet meer welke variant actief is.

**Ops flags** zijn kill switches en circuit breakers. In tegenstelling tot release flags zijn ze ontworpen als permanente infrastructuur. Een `disable_ml_recommendations`-flag die je in staat stelt een trage ML-inferentielaag te omzeilen wanneer zijn SLO degradeert, is iets dat je om 3 uur 's nachts beschikbaar wilt hebben zonder documentatie te lezen. Deze flags moeten lokaal evalueren, een goed gedocumenteerde fallback hebben, en regelmatig worden getest onder normale operaties, niet ontdekt worden onder druk.

**Permission flags** sturen toegang op gebruikersniveau, accountplan of beta-cohort. Ze zijn door design langlevend. Het verwarringrisico: permission flags lijken vaak op release flags voor een lezer die de geschiedenis niet kent. Een duidelijke naamgevingsconventie is hier belangrijker dan waar ook.

![Progressieve software-rollout visualisatie met percentage-gebaseerde verkeersroutering en concentrische knooppunten](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-08/e28abc-inline1.webp)

## Een percentage-rollout zonder SLO-gate is gewoon trage deployment

Hier stoppen de meeste feature flag-implementaties te vroeg. Het platform-team legt een rolloutschema vast: 1% op maandag, 5% dinsdag, 25% woensdag, 100% vrijdag. Ze documenteren het, delen het met stakeholders, en noemen het progressive delivery.

Maar "progressief" zonder een validatieconditie bij elke stap is uitgesteld risico, geen verminderd risico. De percentageschuif regelt de blootstelling. Het valideert de veiligheid niet.

Wat een staged rollout operationeel betekenisvol maakt, is de SLO-gate tussen elke stap. Voor je van 5% naar 25% gaat, moet iets antwoorden: ligt de foutrate op het geflagde codepad binnen het SLO-budget? Houdt de p99-latentie dezelfde bandbreedte als de controlegroep? Brandt het error budget sneller dan baseline?

Als geen van die vragen is geïnstrumenteerd, is het rolloutschema een tijdlijn, geen validatieloop.

Een setup die standhoudt in productie: definieer twee SLO-evaluatievensters. Een kort venster (15 minuten) vangt snelle fouten op: een slechte databasequery, een schema-mismatch, een regressie in een kritiek pad. Een langer venster (24 uur of een volledige verkeerscyclus) vangt geleidelijke degradatie op: geheugenlekken, cache-druk, edge cases in laagfrequent verkeer. Vereis dat beide vensters groen zijn voor elke stap vooruit. Als een venster wordt overschreden, staak de rollout en waarschuw de on-call.

Het percentage is een schuif. Het SLO-venster is de gate. Beide zijn vereist.

## Kill switch engineering: ontwerp het voordat je het nodig hebt

De kill switch is geen fallback. Het is een eerste-klas ontwerpbeslissing die moet bestaan voordat de eerste regel feature-code is geschreven.

Een kill switch ontworpen onder druk is een kill switch met niet-onderzochte aannames. Je test hem voor de eerste keer tijdens een actief incident, in een terminalsessie geopend vanuit een PagerDuty-notificatie, met vijf mensen die een Slack-thread volgen. Dat is het slechtst mogelijke moment om te ontdekken dat je ops flag gebruikers target op session ID en je sessieservice op dit moment gedegradeerd is.

![SLO-monitoring dashboard met error budget burn rate grafieken en kill switch indicator voor feature rollout beheer](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-08/dd1477-inline2.webp)

Drie eigenschappen die niet onderhandelbaar zijn voor een kill switch bestemd voor productiegebruik:

- 
**Lokale evaluatie onder 50ms**: de flag-check kan geen netwerkaanroep zijn naar een externe evaluatieservice. Als de evaluatie afhankelijk is van een service die zelf gedegradeerd kan zijn, heb je een circulaire afhankelijkheid in je incidentresponsepad.

- 
**Expliciete fallbackwaarde**: wat geeft de flag terug wanneer de flag-service onbereikbaar is? Dit moet zijn gedocumenteerd, gedefinieerd in code, en getest. "Wat de SDK-standaard ook is" is geen antwoord.

- 
**Getest onder afhankelijkheidsfalen**: kill switches moeten deel uitmaken van je chaos engineering-rotatie. Valideer ze tegen scenario's waarbij authenticatie gedegradeerd is, waarbij de flag-service zelf down is, en waarbij de netwerklatentie naar het evaluatie-eindpunt meer dan 2 seconden bedraagt.

De teams die incidentrespons goed uitvoeren zijn de teams die hebben geoefend. De kill switch is onderdeel van het runbook. Maak hem saai.

## Flag debt: de technische schuld die niemand op de roadmap zet

Teams die feature flags agressief adopteren, accumuleren vaak wat soms flag debt wordt genoemd: flags die hun doel hebben vervuld maar nooit zijn verwijderd. De feature is geshipped, het experiment is afgerond, de bèta is geëindigd. De flag bleef.

Bij 50 flags is dit een kleine ergernis. Bij 500 flags verspreid over een gedistribueerd systeem is het een actief operationeel risico. Elke flag is een codevertakking die onderhoud, testen en begrip vereist tijdens incidentonderzoek. Een ontwikkelaar die om 2 uur 's nachts een fout probeert te begrijpen, wil niet door 40 conditionele vertakkingen traceren om de relevante te vinden.

Een patroon dat is waargenomen bij meerdere platform-teams: flag-evaluatiemiddleware die verschijnt in de top vijf stack frames voor p99-latentie. De oorzaak is in de meeste gevallen verouderde flags met complexe targetingregels die tientallen condities per verzoek evalueren, de last dragend van beslissingen van twee jaar geleden die niemand prettig vond te verwijderen.

Het tegenmiddel is organisatorisch, niet technisch. Elke aangemaakte flag moet drie attributen hebben: een eigenaar, een type (release, experiment, ops, permission) en een verwachte verwijderdatum. Release flags moeten binnen twee sprints na volledige rollout worden verwijderd. Experiment flags moeten worden verwijderd wanneer het experiment eindigt, niet "wanneer iemand er tijd voor heeft." De flag-inventaris moet op aanvraag controleerbaar zijn en zichtbaar in engineering health dashboards.

## Targeting-granulariteit: de dimensie die breekt op enterprise-schaal

De meeste feature flag-platforms ondersteunen percentage-gebaseerde rollouts en basale gebruikersattribuut-targeting. De kloof die op enterprise-schaal verschijnt is targeting-granulariteit: de mogelijkheid om rolloutregels te formuleren die specifiek genoeg zijn om nuttig te zijn zonder complex genoeg te worden om onbeheerbaar te zijn.

De markt voor feature flag-platforms groeit van $1,45 miljard in 2024 naar een verwachte $5,19 miljard in 2033 (Zylos Research, februari 2026). 78% van enterprise teams rapporteert meer vertrouwen in deployments dankzij progressieve rollout-technieken. AI-gestuurde flag-platforms tonen 73% minder rollout-gerelateerde incidenten vergeleken met statische percentage-rollouts. Die getallen weerspiegelen een verschuiving: targeting-granulariteit is niet langer een premium feature, het is een operationele basisvereiste.

Een nuttige targeting-hiërarchie voor productierollouts op platform-teamniveau:

- 
**Omgevingsniveau**: productie, staging, preview. De eerste gate, niet de enige.

- 
**Infrastructuursegment**: datacenter, availability zone of Kubernetes-cluster. Nuttig om geografisch blast radius te isoleren.

- 
**Account of tenant**: voor B2B SaaS-platforms is rollen per account vaak veiliger dan rollen per gebruikerspercentage, omdat je een volledig verkeerspatroon van een account kunt observeren in plaats van een statistisch sample.

- 
**Gebruikerscohort**: bèta-gebruikers, interne gebruikers, power users op activiteitslaag.

- 
**Sessieattribuut**: nuttig voor experiment flags, gevaarlijk voor ops flags.

De platforms die dit goed implementeren (LaunchDarkly en Statsig worden het meest geciteerd door SRE-teams die dit op schaal doen) staan complexe regelcompositie toe zonder dat engineeringtijd nodig is om de targetinglogica te wijzigen tijdens een actieve rollout. Die zelfbedieningscapaciteit is het verschil tussen een rolloutpauze van 30 seconden en een ticket naar het platform-team.

De platforms die dit slecht implementeren dwingen je te kiezen tussen targeting-granulariteit en operationele eenvoud. Die afweging zal om 3 uur 's nachts opduiken.

## Wat de post-mortem steeds terugvindt

Elke post-mortem voor een feature-gerelateerd productie-incident stelt dezelfde vragen. Was de feature achter een flag geplaatst? Was de rollout progressief? Was er een validatieconditie tussen de stappen? Was de kill switch getest voor het incident?

Als alle vier antwoorden ja zijn, is het incident een kalibratieprobleem: drempelwaarden te los ingesteld, targetingregels met een edge case, SDK-evaluatiegedrag onder netwerkpartitie dat niet was meegenomen. Dit is oplosbaar met configuratiewijzigingen en runbook-updates.

Als een antwoord nee is, is het incident een architectuurprobleem. Feature flags zijn geen debugging-gemak. Het is een deployment-architectuurbeslissing. Die beslissing bestaat voor de feature wordt geshipped, of ze bestaat helemaal niet.

De vraag die het waard is te beantwoorden voor de volgende release: wat zou de post-mortem zeggen over deze rollout als er vanavond iets misgaat?

## FAQ

### Wat zijn feature flags precies?

Feature flags zijn conditionele checks in applicatiecode die bepalen welke codepaden worden uitgevoerd voor een gebruiker, sessie of omgeving, zonder een nieuwe build te shippen. Ze scheiden deployment van release in twee aparte, onafhankelijk bestuurbare gebeurtenissen.

### Wat is het verschil tussen deployment en release met feature flags?

Deployment betekent dat code in productie staat. Release betekent dat gebruikers de feature daadwerkelijk zien. Feature flags maken die twee momenten onafhankelijk: je deployet de code, observeert baseline-metrics, en activeert de feature pas wanneer je klaar bent.

### Wat is een SLO-gate en waarom is die noodzakelijk in een rollout?

Een SLO-gate is een geautomatiseerde validatieconditie tussen rollout-stappen. Voordat je van 5% naar 25% verkeer gaat, beantwoordt hij de vraag of de foutrate en p99-latentie binnen de SLO-budgetten vallen. Zonder gate is een percentage-rollout alleen maar trage deployment.

### Hoe ontwerp je een kill switch die werkt om 3 uur 's nachts?

Drie niet-onderhandelbare eigenschappen: lokale evaluatie onder 50ms (geen netwerkaanroep), een expliciete fallbackwaarde gedefinieerd in code, en regelmatig testen onder afhankelijkheidsfalen als onderdeel van chaos engineering. Ontwerp hem voordat je hem nodig hebt.

### Wat is flag debt en hoe voorkom je het?

Flag debt zijn flags die hun doel hebben vervuld maar nooit zijn verwijderd. Bij 500 flags in een gedistribueerd systeem worden ze een p99-latentieprobleem. Preventie: elke flag krijgt een eigenaar, een type en een verwachte verwijderdatum. Release flags gaan eruit binnen twee sprints na volledige rollout.

### Welke platforms gebruiken SRE-teams voor feature flags op enterprise-schaal?

LaunchDarkly voor enterprise governance en complexe targeting, Statsig voor de combinatie van flags, experimentation en product analytics, ConfigCat voor eenvoud en prijs, en Flagsmith als open-source optie. De keuze hangt af van targeting-granulariteit en de mate van zelfbediening die het platform-team nodig heeft.

### Welke vraag moet je beantwoorden voor elke productie-release?

Wat zou de post-mortem zeggen over deze rollout als er vanavond iets misgaat? Is de feature geflagd? Is de rollout progressief? Is er een SLO-gate tussen de stappen? Is de kill switch getest voor het incident? Als een antwoord nee is, is het een architectuurprobleem, geen kalibratieprobleem.