Wie Flags deine App erreichen

Deine App ruft nicht jedes Mal FortressFlag auf, wenn sie ein Flag prüft. Flag-Lesungen sind lokal — sofort, offline-sicher, kein Netzwerk im Weg. Was über das Netzwerk geht, ist eine periodische Abfrage, und was diese Abfrage holt, hängt davon ab, auf welcher der zwei Planes du bist.

Die Client-Plane: deine Apps bekommen Antworten, keine Regeln

Die iOS-, Android- und Web-SDKs benutzen die Client-Plane. Das Gerät sendet seine Identität und seine Tags; FortressFlag wertet deine Targeting-Regeln serverseitig aus und gibt nur die Werte dieses Geräts zurück — eine kleine Map wie {"new-checkout": true, "dark-mode": false}.

Das Gerät erhält deine Regeln nie. Das ist Absicht, gleich doppelt: Deine Targeting-Logik („Beta-Kohorte“, „interne Geräte“) ist deine Sache und sollte nicht in etwas stecken, das jeder aus einem App-Binary auspacken kann — und die Payload bleibt winzig.

Die Client-Plane authentifiziert sich mit einem Client-Schlüssel (ffc_…), der in deiner App steckt und by design öffentlich ist — mehr dazu unter Schlüssel.

Die Server-Plane: dein Backend bekommt das Ruleset

Das Go-SDK benutzt die Server-Plane. Dein Server lädt das vollständige Ruleset für ein Projekt + Umgebung herunter — Arten, Standards, Regeln, mit bereits eingeflachten Segmenten — und wertet Flags in seinem eigenen Prozess aus. Eine Flag-Prüfung ist ein Funktionsaufruf auf Daten, die bereits im Speicher liegen: kein Netzwerk-Hop pro Prüfung, keine Latenz pro Request, und eine Abfrage versorgt deinen ganzen Prozess, egal wie viele Requests er bedient.

Weil das Ruleset deine Targeting-Regeln enthält, sitzt diese Plane hinter einem Server-Schlüssel (ffs_…) — einem echten Geheimnis, behandelt wie ein Datenbankpasswort. Und da deine Regeln jeden Server erreichen, der diesen Schlüssel hält, liegt die Konsequenz bei dir: Leg keine Geheimnisse oder personenbezogenen Daten deiner Nutzer in Regelbedingungen.

Auf dieser Plane gibt es keine Geräteidentität. Dein Code übergibt pro Auswertung einen Kontext-Key — eine User-ID, eine Session-ID, was auch immer du zum Bucketing nimmst — und die Rollout-Arithmetik benutzt ihn genau so, wie die Client-Plane die Geräte-ID benutzt, sodass dieselbe Eingabe in derselben Kohorte landet, egal welche Plane sie auswertet.

Polling, und warum es günstig ist

Beide Planes fragen in einem Intervall ab, und beide benutzen bedingte Requests: Jede Antwort trägt einen Validator (ein ETag), und wenn sich seit der letzten Abfrage nichts geändert hat, ist die Antwort ein winziges „nichts geändert“ — kein Body, keine erneute Auswertung. Der stationäre Zustand einer Flotte, die keine Flags ändert, ist ein Strom fast kostenloser Prüfungen.

Wenn du doch etwas änderst — ein Umschalten, eine Regel, ein Zeitplan, der auslöst — holt die nächste Abfrage es vollständig ab. In der Praxis erreicht eine Änderung online befindliche Client-Geräte innerhalb von etwa einer Minute.

(Eine Abrechnungsnotiz: Eine „nichts geändert“-Antwort zählt trotzdem als Aktivität für die Zahl der monatlich aktiven Geräte — aber denk daran, ein Gerät zählt einmal pro Monat, egal wie oft es abfragt.)

Das Fallback-Versprechen

Ein FortressFlag-Ausfall darf deine App niemals mitreißen. Jedes SDK behält die zuletzt empfangenen Werte in einem dauerhaften lokalen Cache und löst Flags über dieselbe Kaskade auf:

1. Die zuletzt empfangenen Werte — auch aus einem früheren Lauf. Ein Gerät, das einen Monat offline war, liefert, was es zuletzt gesehen hat; Veraltetes ist überraschenden Regressionen vorzuziehen.
2. Der Standard deines Codes — der Wert an der Aufrufstelle — wenn noch nie etwas empfangen wurde. (Client-SDKs landen bei false für Boolean-Lesungen ohne Standard.)

Zwei Konsequenzen, die du kennen solltest:

• Ein widerrufenes oder fehlschlagendes Credential macht deine App nicht kaputt. Das SDK liefert weiter aus seinem Cache und versucht es weiter. Fehler erreichen deine Nutzer nie über eine Flag-Lesung.
• Eine Payload, die das SDK nicht verifizieren kann, wird behandelt wie gar keine Payload. Jede Antwort ist signiert, und das SDK prüft die Signatur, bevor sich irgendetwas ändert — siehe Payload-Signierung.
• Ein Flag zu archivieren schaltet es wirklich aus. Wenn ein Flag die Payload verlässt, entfernt das SDK es bei derselben Abfrage aus den Live-Werten und dem Cache — innerhalb von etwa einer Minute lösen Online-Geräte überall den Standard deines Codes auf. Der Cache bewahrt entfernte Flags nie — täte er es, könnte Archivieren einen Rollout nicht endgültig beenden.

Wie geht es weiter?

• Schlüssel — ffc_ vs. ffs_, und warum der eine öffentlich ist und der andere jemanden aus dem Bett holt
• Geräteidentität und Abrechnung — was die Identität der Client-Plane ist
• Installiere ein SDK — wähl deine Plattform und bring ein Flag live