Was passiert, wenn Rexfins Verifier ausfällt (und wie er sich erholt)

Rexfins Verifikationsengine steht im Zentrum jeder zitierten Antwort und jeder Export-Entscheidung. Das ist keine beiläufige Abhängigkeit – das ist der ganze Punkt. Einen unverifizierten Export zu blockieren, ist nur dann etwas wert, wenn die Instanz, die blockiert, auch tatsächlich läuft, schnell antwortet und beobachtbar ist, wenn es darauf ankommt. Die ehrliche Frage lautet also nicht „hat Rexfin Verfügbarkeit”, sondern „was passiert in dem Moment, in dem es sie nicht hat”.

Ein Budget, keine Hoffnung

Sowohl der Verifikationspfad als auch der Antwortpfad tragen ein gemessenes Service-Level-Ziel, keine Wunschvorstellung. Die Verifikation eines bereits eingereichten Modells zielt auf eine p95-Antwortzeit von rund 8 Sekunden; eine frisch zitierte Antwort, bei der vor der Verifikation noch Retrieval und Generierung anfallen, zielt auf p95 innerhalb ihres gesamten Budgets und eine harte p99-Obergrenze. Die Verfügbarkeit wird gegen ein Ziel von 99,5 % über ein rollierendes 30-Tage-Fenster gemessen, mit einem daran gekoppelten Fehlerbudget.

Warum ein Budget mehr aussagt als eine einzelne Verfügbarkeitszahl: Es hängt eine Burn-Rate-Alarmierung daran. Ein plötzlicher Totalausfall löst innerhalb der ersten Stunde eine Benachrichtigung aus, nicht erst am Monatsende, wenn das Budget längst aufgebraucht ist. Eine langsame, schleichende Verschlechterung öffnet ein Ticket, lange bevor das Budget zur Neige geht. Und eine berechtigte Verweigerung – der Verifier blockiert korrekt einen Zahlensatz, der eine Identitätsprüfung nicht besteht – zählt als funktionierendes System, nicht als Ausfall. Diese Unterscheidung ist wichtig: Eine Verfügbarkeitskennzahl, die nicht zwischen „das Gate hat seine Arbeit getan” und „das Gate ist kaputt” unterscheiden kann, misst das Falsche.

Eine Trace-ID über die gesamte Antwort hinweg

Wenn ein Urteil zu langsam oder falsch ist, verläuft der Fehler meist über mehrere Grenzen hinweg – Retrieval, dann eine Recherche-Schleife, die stützende Zahlen zusammenträgt, dann ein Writer, der den Text formuliert, dann der Verifier, der ihn prüft, dann das Schreiben in den Audit-Log. Rexfin verknüpft all das unter einer einzigen Trace-ID, damit eine langsame Antwort Ende-zu-Ende diagnostizierbar ist, statt bei „irgendwo ist es langsam” stehen zu bleiben – dem am wenigsten hilfreichen Satz in jeder Incident-Analyse. Jede Trace, die in einem Fehler oder einer berechtigten Verweigerung endet, wird immer vollständig aufbewahrt, unabhängig vom normalen Sampling, damit ausgerechnet die interessanten Fälle nie diejenigen sind, die verworfen wurden.

Anbieter fallen aus. Die Antwort muss deshalb nicht einfach stehen bleiben.

Modellanbieter drosseln und fallen aus – das ist normal, keine Ausnahme. Rexfin umhüllt jeden ausgehenden Aufruf mit einem Timeout, begrenzten Wiederholungsversuchen mit Backoff und einem Circuit Breaker pro Anbieter. Löst ein Breaker aus, weicht die Anfrage auf einen zwischengespeicherten oder Offline-Pfad aus, statt hängen zu bleiben, und die Antwort wird ehrlich als eingeschränkt gekennzeichnet – nie stillschweigend so zurückgegeben, als wäre nichts passiert. Das macht die Verteilung unterschiedlicher Aufgaben auf unterschiedliche Modellanbieter betrieblich sicher: Ein Ausfall bei einem einzelnen Anbieter beeinträchtigt die Antworten einer Rolle, nicht das gesamte System.

Wiederholungsversuche tragen eine zweite Garantie, die leicht übersehen wird: Sie sind idempotent. Wiederholt ein Client dieselbe Verifikationsanfrage zweimal, liefert Rexfin dasselbe gespeicherte Urteil und denselben Audit-Eintrag zurück, statt einen zweiten Eintrag an den Audit-Log anzuhängen. Ein append-only, manipulationssicheres Protokoll, das durch gewöhnliche Netzwerk-Wiederholungen doppelte Einträge ansammeln könnte, wäre nicht lange vertrauenswürdig.

Darunter liegt eine Regel, die sich nie biegt: Eine ausgefallene Abhängigkeit degradiert zu einem Hinweis, einem typisierten Fehler oder einer Verweigerung – sie erzeugt niemals ein bestandenes Urteil für eine Prüfung, die tatsächlich gar nicht laufen konnte. Fällt die Datenbank aus, sagt das Gate „nicht verfügbar”, nicht „sauber”.

Das Backup, auf das es wirklich ankommt

Die folgenreichste Garantie in diesem gesamten Bereich betrifft nicht die Verfügbarkeit – sie betrifft das, was eine Wiederherstellung überlebt. Jeder verifizierte Board-Pack, den Rexfin je ausgegeben hat, ist nur so gut wie der manipulationssichere Datensatz dahinter. Würde ein Festplattenausfall oder ein fehlgeschlagenes Deployment dazu führen, dass dieser Datensatz nicht in einen Zustand zurückversetzt werden könnte, in dem sein Beleg noch standhält, würde jedes zuvor ausgegebene Urteil im Nachhinein still und leise unüberprüfbar werden.

Deshalb gilt die Wiederherstellungsprozedur nicht schon dann als abgeschlossen, wenn die Datenbank wieder online ist. Sie gilt erst dann als abgeschlossen, wenn der Beleg eines zuvor ausgegebenen Urteils gegen die wiederhergestellten Daten erneut geprüft wird und weiterhin standhält – derselbe Beleg, den der eigene Wirtschaftsprüfer eines Kunden unabhängig nachvollziehen könnte. Backups laufen kontinuierlich statt als nächtliche Snapshots, zielen auf ein Datenverlustfenster im Minutenbereich und werden nach Zeitplan geübt, damit die Wiederherstellung eine getestete Fähigkeit ist und kein Dokument, das noch nie jemand tatsächlich ausgeführt hat. Genau hier berühren sich Aufbewahrung und Löschung mit der Zuverlässigkeit: Die Daten eines gelöschten Deals müssen auch aus den Backups tatsächlich verschwunden sein und dürfen nicht beim nächsten Restore still wieder auftauchen.

Nichts davon macht Rexfin immun gegen Ausfälle – Anbieter fallen weiterhin aus, Festplatten versagen weiterhin. Was sich ändert, ist das, was danach passiert: eine gemessene, alarmierte und letztlich beweisbare Wiederherstellung statt der stillen Hoffnung, dass nichts Wichtiges verloren ging. Für den Rest der Frage, wie die Plattform durchgehend verteidigbar aufgebaut ist, siehe den Inside-the-Rexfin-Platform-Hub.