Wat is een feature flag? Een SRE-antwoord, met code

Het is 03:12 en het foutenpercentage van de checkout is net boven 4 procent gekomen. De wijziging die dit veroorzaakte, ging zes uur geleden live. Niemand wil de hele release terugdraaien, want die bevat ook twee niet-gerelateerde fixes. Wat is een feature flag in zo'n situatie? Het is een conditie in je code die tijdens runtime wordt gelezen en bepaalt of een codepad wordt uitgevoerd. Zet je de flag uit, dan stopt het nieuwe pad met draaien, zonder build en zonder deploy. Dat is het hele idee. De rest is operations.

Wat een feature flag echt is (en wat niet)

Een feature flag is een beslismoment. Ergens in de code staat een if, en de waarde waarop die reageert, komt van buiten de binary: een configuratieservice, een databaserij, de SDK van een leverancier of een environment variable die je kunt wijzigen zonder herstart.

const useNewPricing = await flags.isEnabled("new-pricing-engine", {
  userId: user.id,
  plan: user.plan,
  region: request.region,
});

return useNewPricing
  ? newPricingEngine.quote(cart)
  : legacyPricing.quote(cart);

Uit dat fragment volgen drie dingen. Het oude pad moet nog bestaan en moet nog werken. De flag heeft context nodig (wie vraagt erom) als je iets slimmers wilt dan aan of uit. En de evaluatie zit op het hot path van een request, dus de latency en het foutgedrag zijn nu jouw probleem.

Mensen gebruiken "feature toggle" en "feature flag" door elkaar. Het woord doet er niet toe. Het gedrag wel: je scheidt het uitrollen van code van het vrijgeven ervan. De code gaat donker naar productie, en een persoon of een systeem beslist later wie hem te zien krijgt.

De vier soorten flags, en waarom mengen pijn doet

Het grootste deel van de pijn met flags komt doordat alle flags als één ding worden behandeld. De taxonomie van feature toggles van Martin Fowler splitst ze op hoe lang ze leven en hoe dynamisch de beslissing is. In de praktijk klopt die indeling.

Release toggles zijn tijdelijk. Ze verbergen onaf werk achter een flag, zodat je dagelijks naar trunk kunt mergen. Volgens Fowler horen ze zelden langer dan een week of twee te bestaan. De beslissing is statisch: elk verzoek voor een bepaalde release krijgt hetzelfde antwoord.

Experiment toggles sturen verschillende gebruikers naar verschillende varianten. Ze blijven zo lang staan als nodig is om statistische significantie te halen, uren tot weken, en niet langer. De beslissing wordt per verzoek genomen.

Ops toggles sturen operationeel gedrag: een niet-kritieke functie uitschakelen onder belasting, overschakelen naar een fallback-dependency of een dure query uitzetten. Een paar daarvan worden langlevende kill switches. Die moeten binnen seconden kunnen omklappen, en dat sluit alles uit wat een release nodig heeft.

Permission toggles bewaken functies op basis van abonnement of recht. Ze kunnen jaren meegaan, en de beslissing wordt bij elk verzoek per gebruiker genomen.

De fout is dat je alle vier dezelfde levenscyclus geeft. Een permission toggle heeft voor altijd een eigenaar en een audit trail nodig. Een release toggle heeft een verwijderdatum nodig op de dag dat hij wordt aangemaakt. Als je aan de naam van een flag niet kunt zien wat voor soort het is, kun je ook niet bepalen welke je veilig kunt verwijderen.

Waarom SREs erom geven: flags als blast radius-regelaar

Voor een platformteam is de interessante eigenschap niet A/B-testen. Het is dat een flag een release verandert van een gebeurtenis in een draaiknop.

Zonder flags stelt een deploy 100 procent van het verkeer in één keer bloot aan de wijziging. De enige terugdraai is een nieuwe deploy, en die duurt zo lang als je pipeline, plus de tijd die een mens nodig heeft om zeker te zijn. Met flags kun je 1 procent van de gebruikers blootstellen, het foutpercentage en de p99 in de gaten houden, en daarna naar 5, 25 en 50 gaan. De blast radius is het percentage dat je kiest, en de terugdraai is een configuratiewijziging die binnen seconden doorkomt.

Dat verandert je mean time to recover meer dan de meeste tooling-investeringen. De vraag in de postmortem wordt dan niet meer "waarom duurde het 40 minuten om terug te draaien", maar "waarom zat dit niet achter een flag".

Een rollout-draaiknop heeft wel een keerzijde: iemand moet de signalen volgen en hem bedienen. Om 03:12 is die iemand moe. De bruikbare variant van een flagsysteem koppelt de draaiknop aan een service level objective. Als het foutpercentage een vastgesteld deel van het budget opeet, stopt de rollout en draait hij terug, zonder mens in de lus. De meeste teams bouwen dit zelf met een webhook van hun alerttool naar de flag-API. Het is een paar honderd regels code, en het verdient zich terug in de eerste nacht dat het afgaat.

De rekening komt: flagschuld en de les van Knight Capital

Elke flag die je toevoegt, verdubbelt in theorie het aantal paden door die code. In de praktijk test je een handvol combinaties en hoop je dat de rest goed gaat. Fowler adviseert om flags te behandelen als inventaris met kosten: voeg bij het aanmaken een verwijderingstaak toe aan de backlog, geef ze vervaldatums, en laat in de strengste teams de build falen zodra een verlopen flag nog in de code staat.

De duurste versie van deze les is Knight Capital. Op 1 augustus 2012 hergebruikte een nieuwe deployment een oude flag die ooit een uitgefaseerde functie had aangestuurd. Eén server miste de deployment en draaide nog de oude code. In de eerste 45 minuten na de opening stuurde de router van het bedrijf meer dan 4 miljoen orders de markt in, terwijl er 212 klantorders uitgevoerd moesten worden, zoals de SEC-zaak tegen Knight Capital vastlegt. Fowler noemt het verlies, rond de $460 miljoen, als waarschuwing voor flags die je niet beheert.

De flag was niet de enige oorzaak. Handmatige deployments, geen kill switch en trage detectie speelden ook mee. Maar het hergebruiken van een dode flagnaam is het detail dat elk platformteam op een muur zou moeten hangen. Hergebruik nooit een flag. Verwijder de oude, maak een nieuwe aan, en maak het verwijderen een volwaardige stap.

Zelf bouwen of een flagplatform kopen?

Een zelfgebouwd flagsysteem begint als een configuratiebestand en een boolean. Dat is prima voor de eerste tiental release toggles op één service. Het wordt een probleem zodra je percentage-rollouts nodig hebt die per gebruiker stabiel blijven, targetingregels per segment, een audit log van wie wat wijzigde, en een flagwijziging die in seconden elke instantie bereikt zonder een kudde die tegelijk op je configuratiestore afkomt.

Op dat punt vergelijk je platforms op meetbare criteria: de latency van SDK-evaluatie (lokaal evalueren versus een netwerkaanroep), streaming of polling voor updates, de granulariteit van targetingregels, ondersteuning voor meerdere omgevingen, en hoe het prijsmodel meeschaalt met je verkeer.

De prijsmodellen verschillen meer dan de featurelijsten.

LaunchDarkly is de referentie-implementatie van de categorie: volwassen targeting, guarded releases en een diepe integratielaag. De prijzen zijn gebruiksgebaseerd en worden berekend per service-connectie en per duizend maandelijkse actieve client-side gebruikers. Een consumentenapp met een groot anoniem publiek kan dus een rekening krijgen die anders beweegt dan bij een team dat alleen backend draait. Het sterke punt is dat het platform het langst is uitgetest op enterprise-schaal, als je governance en audit nodig hebt.

Statsig combineert flags met experimenten en productanalyse, en rekent per event. Dat past bij teams die flags vooral als experimentoppervlak gebruiken. Als je vooral ops toggles en kill switches nodig hebt, betaal je voor analyse die je misschien nooit leest. Let daarnaast op: de eigenaar van de leverancier is sinds september 2025 al twee keer veranderd, wat de moeite waard is om mee te nemen in je vendor-risicobeoordeling.

Wat je ook kiest, test het faalgedrag voordat je tekent. Blokkeer de netwerktoegang van de SDK in staging en kijk wat de applicatie doet. Een goede SDK serveert de laatst bekende flagwaarden uit de cache en logt dat luid. Een slechte SDK blokkeert het requestpad.

Observability is de helft van het flagsysteem

Een flag zonder telemetrie is een gok. Het minimale bruikbare setup koppelt de flagstatus aan elke trace en elke logregel van het request, zodat je bij een foutpiek kunt groeperen op flagvariant en ziet of het nieuwe pad de oorzaak is.

Datadog en vergelijkbare alles-in-één-platforms maken de uitsplitsing per variant eenvoudig zodra je SDK spans van tags voorziet. Let wel op: de kosten per host en per signaal stijgen snel als je tags met hoge cardinaliteit toevoegt, zoals flagsleutel plus variant plus gebruikerssegment. Kies bewust welke dimensies je taggt.

Grafana is de goedkopere route als je al Prometheus en OpenTelemetry draait. Je bouwt de flagbewuste dashboards zelf, wat engineeringtijd kost, maar je houdt volledige controle over de labels die je uitstuurt. Voor een team van 50 tot 500 engineers met een platformgroep is die afweging vaak de juiste.

Een korte runbook voor je eerste flag in productie

Als je flags introduceert in een team dat er nog geen heeft, houd de eerste rollout saai.

1. Kies één wijziging met een helder succesmetric, zoals het foutpercentage van de checkout of de p99-latency van één endpoint.

2. Geef de flag een naam met type en eigenaar, bijvoorbeeld release.checkout.new-tax-calc.owner-payments.

3. Schrijf nu het verwijderingsticket en zet er een vervaldatum op van hooguit twee weken.

4. Rol uit naar 1 procent, houd dat vast voor één volledige verkeerscyclus en ga dan omhoog. Bepaal vooraf de drempel waarop je terugdraait.

5. Maak de terugdraai een enkel commando of een knop, en oefen die één keer in staging voordat je hem 's nachts nodig hebt.

6. Nadat 100 procent een paar dagen stabiel is gebleven, verwijder je de flag en het oude codepad in dezelfde wijziging.

Het oncharmante deel is stap 6. Teams die die overslaan, eindigen met een paar honderd flags, niemand die weet wat de helft ervan doet, en een Knight-achtig risico in de repository.

Hoe had je laatste incident eruitgezien achter een flag?

Neem het laatste productie-incident dat je team heeft uitgewerkt. Stel drie vragen. Had de wijziging donker kunnen uitgaan? Had één persoon hem in minder dan een minuut kunnen uitzetten, zonder deploy? Had een alert je verteld welke variant faalde?

Als de antwoorden nee, nee en nee zijn, heb je je eerste flagkandidaat en je eerste eerlijke schatting van wat een terugdraai je vandaag kost. De postmortem zegt wat hij zegt. De betere vraag is hoeveel kleiner je het had kunnen maken voordat de pager afging.