Was sind Feature Flags?

Was sind Feature Flags?

Feature Flags (auch Feature Toggles, Feature Gates oder Release Toggles genannt) sind bedingte Checks im Code, die Anwendungsverhalten in Production ein- oder ausschalten, ohne neu zu deployen. Der Check sieht aus wie if (featureFlags.newCheckoutFlow) { /* neuer Code */ } else { /* alter Code */ }. Der Wert von newCheckoutFlow wird zur Laufzeit von einem Flag-Service abgerufen — LaunchDarkly, ConfigCat, GrowthBook oder dein eigenes selbstgebautes System — und kann sich für jeden Nutzer, Prozentsatz des Traffics oder spezifische Kohorte sofort ändern.

Die Kern-Erkenntnis: Deploy ≠ Release. Ohne Flags bedeutet Code shippen, ihn für alle live zu machen. Mit Flags kann Code hinter einem Flag in Production shippen, wochenlang dunkel bleiben, während du ihn intern tunest, dann progressiv auf 1%, 5%, 50%, 100% der Nutzer ausgerollt werden. Wenn etwas bricht, flip das Flag zurück. Kein Redeploy, kein Rollback, keine Panik.

Die vier kanonischen Use Cases

1. Release-Toggles (graduelles Rollout)

Code zu Production hinter einem Flag shippen, standardmäßig aus. Graduell für interne Nutzer aktivieren → Beta-Kohorte → 1%-Canary → 10% → 100%. Wenn Metriken in irgendeiner Phase degradieren (Fehler spiken, Conversion fällt, p95-Latenz steigt), flip das Flag sofort zurück. Ohne Flags müsstest du redeployen oder git-reverten, um zu erholen.

2. Experiment-/A/B-Test-Toggles

50% der Nutzer sehen Version A, 50% sehen Version B. Der Flag-Service trackt, welcher Nutzer welche Variante bekam. Analytics korrelieren Nutzeraktionen mit Variante. Statistische Analyse entscheidet den Gewinner. Große Experimentations-Plattformen (Optimizely, LaunchDarkly Experiments) bauen vollständig auf diesem Primitive.

3. Permission-/Entitlement-Toggles

Verschiedene Nutzer sehen verschiedene Features basierend auf Plan-Tier, Organisation oder Rolle. "Nur Pro-Plan"-Features sind Flag-gated; der Wert des Flags hängt vom Account-Status des Nutzers ab. Funktional ähnlich zu traditioneller Autorisierung, aber im selben Flag-Dashboard wie Releases verwaltet.

4. Kill-Switches (operative Toggles)

Wrappe riskante oder teure Code-Pfade (Drittanbieter-API-Calls, Empfehlungs-Engines, ML-Inferenz) in Flags, damit du sie unter Last oder während Incidents deaktivieren kannst. Site fällt aus, weil die Empfehlungs-API timeoutet? Flip das Flag, fall zurück auf eine einfachere Erfahrung, behandle den Drittanbieter in Ruhe.

Wie Feature-Flag-Systeme funktionieren

Die Architektur unter der Haube:

• Flag-Definitionen zentral gespeichert. Ein Web-Dashboard lässt Produkt/Engineering-Teams Flags definieren, Targeting-Regeln setzen ("100% der Nutzer in EU", "10% der Nutzer mit plan=pro", "diese spezifische user_id-Liste") und ein/ausschalten.
• Client-SDKs in deiner Anwendung. Deine App fetcht Flag-Werte vom Service entweder beim Startup (im Speicher gecacht) oder pro Request (typischerweise mit aggressivem lokalem Cache). SDKs existieren für jede große Sprache und jedes Framework.
• Streaming-Updates. Moderne Flag-Services nutzen WebSockets oder Server-Sent Events, um Flag-Wert-Änderungen innerhalb von Millisekunden an laufende Clients zu pushen. Flag im Dashboard toggeln; Production-Traffic shiftet Sekunden später.
• Telemetrie zurück. Flag-Services capturen, welche Flag-Werte welche Requests bedienten, was Auditing ("wer hat dieses Flag um 03:42 geflippt?") und Experimentation (Korrelation von Nutzerverhalten mit Variante) ermöglicht.

Build vs. Buy: die vier echten Optionen

• Buy: LaunchDarkly. Der Markt-Leader. Reifes SDK-Ökosystem, ausgeklügeltes Targeting, teuer im Maßstab (1k-50k+ $/Jahr). Pay-for-Confidence-Option.
• Buy: ConfigCat / Flagsmith / Statsig. Günstigere Alternativen, anständige Feature-Sets, schneller zu evaluieren. ConfigCat hat einen großzügigen kostenlosen Tier; Flagsmith ist Open-Source-und-selbst-hosten-friendly.
• Buy: GrowthBook (Open Source). Besonders stark für Experimentation-Use-Cases. Selbst hosten oder die SaaS-Version nutzen.
• Build: in-house. Ein einfacher Flag-Service ist ~500 Zeilen Code: Flag-Definitionen in einer Datenbank, eine API zum Abrufen, ein Dashboard, basic Targeting-Regeln. Wert zu bauen, wenn du spezifische Compliance-Anforderungen hast (Daten müssen in deiner VPC bleiben) oder die Bedürfnisse deines Teams schmal sind. Die meisten Teams unterschätzen den langfristigen Wartungsaufwand.

Häufige Feature-Flag-Fallen

• Flag-Explosion. Ohne Governance shippen Teams Flags, löschen sie aber nie. Nach einem Jahr hat die Codebase 200 Flags, von denen die Hälfte nicht mehr gebraucht wird. Setze eine Policy: jedes Flag hat ein Verfallsdatum und einen Owner; Cleanup ist Teil der Release-Definition-of-Done.
• Verstecktes Coupling zwischen Flags. Flag A macht nur Sinn, wenn Flag B an ist. Ohne explizite Abhängigkeiten flippt ein Teammitglied B aus und bricht A. Halte Flag-Beziehungen dokumentiert; erwäge ein "Compound-Flag"-Feature im Service.
• Test-Matrix-Explosion. 10 unabhängige Boolean-Flags = 1024 mögliche Code-Pfade. Du wirst nicht alle QA'en. Nutze Prerequisite-Flags, teste die meistgenutzten Kombinationen und verlasse dich auf Production-Observability für den Rest.
• Latenz auf Cold-Cache. Erstes Flag-Fetch beim App-Startup blockiert den Request. Pre-warm den Cache, nutze Streaming-SDKs oder falle auf sichere Defaults zurück, wenn der Flag-Service nicht erreichbar ist.
• Flag-Service als Single-Point-of-Failure. Wenn der Flag-Service down geht, muss deine App weiterarbeiten. SDKs cachen typischerweise die letzten-bekannten-guten Werte und fallen graceful zurück — aber verifiziere, dass das stimmt, und teste es (führe ein Chaos-Experiment durch, das Flag-Service-Netzwerk-Calls blockiert).
• Stecken in Flag-Purgatory. Flag geht von 0% → 50% → stuck. Owner wechselt Teams, Flag erreicht nie 100%. Die Cleanup-Hälfte ist schwerer als die Rollout-Hälfte. Bau es in deinen Prozess ein oder du ertrinkst in Cruft.

Feature Flags vs. Config Flags vs. Environment Variables

Drei verwandte Konzepte:

• Feature Flags: Laufzeit-veränderbar, oft pro-Nutzer-getargetet, manchmal A/B-getestet. Angetrieben von einem Flag-Service.
• Config Flags: Anwendungs-Konfiguration (Datenbank-Connection-Strings, API-Keys, Timeouts). Üblicherweise pro Umgebung gesetzt, geändert via Redeploy oder Config-Reload.
• Environment Variables: OS-Level-Konfiguration. Fundamental, aber unflexibel — Änderungen erfordern Prozess-Neustart.

Verwechsle sie nicht. Feature Flags sind für Produkt-/Release-Entscheidungen; Config ist für operative Parameter; Environment Variables sind für System-Bootstrap.

FAQ: Feature Flags

Sind Feature Flags Overkill für kleine Teams?

Nicht mehr. Tools wie ConfigCat haben kostenlose Tiers, nutzbar für kleine Teams. Auch ein einzelner Dev-Shop profitiert von Kill-Switches und gradeullen Rollouts. Der Overhead eines Flag-Services ist klein verglichen mit den Firefighting-Kosten eines schlechten Releases.

Was ist der Unterschied zwischen Feature Flags und Trunk-Based-Development?

Sie sind komplementär. Trunk-Based-Development bedeutet, dass jeder Commit zu main geht; Feature Flags lassen dich unvollständigen Code sicher in main behalten, ohne dass Nutzer ihn sehen. Zusammen ermöglichen sie Continuous Integration ohne lang-lebige Branches.

Wie wirken Feature Flags aufs Testing?

Teste den Flag-on-Pfad UND den Flag-off-Pfad. CI-Matrix-Builds mit beiden Zuständen. Für Multi-Flag-Systeme priorisiere die in Production tatsächlich genutzten Kombinationen. Manche Flag-Services (LaunchDarkly, Statsig) integrieren mit Test-Runnern, um spezifische Flag-States fürs Testing zu injizieren.

Können Feature Flags Performance schädigen?

Wenn schlecht implementiert, ja — einen Flag-Wert bei jedem Request ohne Caching zu fetchen, fügt Latenz hinzu. Moderne SDKs cachen aggressiv (im Speicher) und updaten via Streaming, also sind die Pro-Request-Kosten Mikrosekunden, nicht Millisekunden. Audite dein SDK-Setup, wenn Flag-Latenz hoch wirkt.

Sollte ich Feature Flags für Permissions nutzen?

Geteilte Meinung. Pro: dasselbe Dashboard für Releases + Entitlements. Contra: Flag-Services sind typischerweise nicht für feingranulare ACL mit Audit-Trails gebaut. Für komplexe Permission-Modelle nutze einen dedizierten Authz-Service (Permit.io, OpenFGA, AWS Cedar). Für einfaches Plan-Tier-Gating sind Flags okay.

Wie interagieren Feature Flags mit Analytics?

Best Practice: sende den aktiven Flag-State (oder die Experiment-Variante) als Event-Property an dein Analytics-Tool. Das lässt dich Metriken nach Variante slicen und bestätigen, dass Experimente statistisch valide sind. Ohne das kannst du nicht sagen, ob ein Metrik-Drop von einer Flag-Änderung oder organischem Rauschen kommt.

Wie LoadFocus zu Feature-Flag-Rollouts steht

Feature-Flag-Rollouts sind genau dann, wenn Lasttest am wichtigsten ist. Neue Code-Pfade, die für 10% des Traffics geflippt werden, könnten teure Endpoints plötzlich anders hämmern als der alte Code. LoadFocus-Lasttest gegen den neuen Code-Pfad vor dem Flag-Flip validiert, dass er im Maßstab hält. API-Monitoring während des Rollouts fängt Latenz-Regressionen in Echtzeit, sodass du zurückflippen kannst, bevor Nutzer es bemerken.