Feature-Flag-Dienst im Detail: Regelwerke, lokale Auswertung und stabile Prozent-Rollouts

Ziel

Flags in jedem Dienst einheitlich auswerten, sie ohne Deploy ändern, nach Prozentsatz ausrollen, ohne dass Nutzer zwischen Varianten wechseln, und die Auswertung auch dann funktionsfähig halten, wenn der Flag-Dienst ausfällt.

Voraussetzungen

Eine Liste der Umgebungen, die für das Targeting verfügbaren Attribute (Nutzer-ID, Mandant, Region, App-Version) sowie eine Vereinbarung, dass Flags ablaufen, sofern sie nicht als betrieblich markiert sind.

Schritte

1. Randbedingungen: Die Auswertung ist lokal und günstig; dasselbe Subjekt erhält in jedem Dienst dieselbe Variante; jede Änderung ist zurückverfolgbar; clientseitige SDKs dürfen keine Regeln erhalten, die Targeting-Daten preisgeben.
2. Komponenten: ein Definitionsspeicher mit einer Admin-API; ein Verteiler, der per Polling oder Streaming das vollständige Regelwerk je Umgebung mit einer Version und einem ETag ausliefert; SDKs, die das Regelwerk cachen und lokal auswerten; eine Konvention für den Auswertungskontext, den die OpenFeature-Spezifikation als für die Flag-Auswertung genutzte Umgebungsinformation beschreibt, die für Targeting, Overrides und anteilige Auswertung verwendet wird; ein Änderungsprotokoll.
3. Datenmodell: flag(key, env, type, variants[], default_variant, enabled, rules[], version, owner, expires_at); rule(conditions[], variant | rollout{variant: percent}); change(flag, env, author, before, after, at); ausgeliefert als ein einziges ruleset(env, version, flags[])-Dokument.
4. Stabile Rollouts: flag_key + subject_key in einen Bucket von 0 bis 9999 hashen und mit dem Rollout-Prozentsatz vergleichen; derselbe Hash in jedem SDK hält ein Subjekt über Dienste hinweg und mit wachsendem Prozentsatz in seiner Variante. Nie pro Auswertung eine Zufallszahl ziehen.
5. Fehlermodi: Verteiler ausgefallen (SDKs behalten das letzte Regelwerk im Speicher und auf der Platte und fallen erst bei einem Kaltstart auf Code-Standardwerte zurück); Versionsdrift zwischen Diensten für Sekunden nach einer Änderung (akzeptieren; bei Entscheidungen, die übereinstimmen müssen, einmal am Rand auswerten und das Ergebnis weiterreichen); Browser oder mobile Apps, die das vollständige Regelwerk erhalten (nicht vertrauenswürdigen Clients vorab ausgewertete Werte ausliefern); Flags, die nie ablaufen (Auswertungen je Flag und Alter berichten); eine Regel, die sich auf ein im Kontext fehlendes Attribut bezieht (das Fallthrough-Verhalten explizit festlegen).
6. Messen: Verbreitungszeit des Regelwerks, Auswertungen je Flag und Tag (null bedeutet tot), Anteil der Auswertungen, die Standardwerte verwendeten, Flags jenseits von expires_at, Änderungen pro Tag nach Autor.
7. Nicht zuerst: Experimentstatistik, ein visueller Regel-Builder, Abhängigkeiten zwischen Flags, Overrides pro Anfrage, geplante Änderungen.

Erwartetes Ergebnis

Eine Änderung erreicht alle Dienste innerhalb der Verbreitungsschranke, kein Subjekt wechselt während eines Rollouts hin und her, und ein Ausfall des Flag-Dienstes belässt jeden Dienst beim zuletzt bekannten Regelwerk.

Grenzen und Prüfbasis

Vorgeschlagenes Design, keine Messungen. Toggle-Typen und Aufräumdisziplin stehen im Artikel zu Feature Toggles; dieser Durchgang deckt den Dienst und seinen SDK-Vertrag ab.