Programmdienste

Manches, was ein Handelsplatz über ein Konto wissen muss, lässt sich nicht während der Blockausführung berechnen. Eine Volumenstufe hängt an dreißig Tagen Handel. Eine Prämie hängt an einem Zeitfenster, das noch nicht geschlossen ist. Eine Empfehlungszuordnung hängt an einer Beziehung, die vor Monaten entstanden ist. Diese Arbeit in die Blockausführung zu verlagern, wäre gleich doppelt falsch: Jeder Block müsste für eine Berechnung zahlen, die fast kein Block braucht, und der Kernel müsste Historie mitführen, für die er sonst keinen Grund hat. Programmdienste lösen das, indem sie die Richtung umkehren. Die Berechnung läuft außerhalb des Blocks, über den festgeschriebenen Datensatz. Ihr Ergebnis wird anschließend zurück auf die Chain geschrieben, als Protokollzustand, den die Ausführung wie jede andere Konfiguration in konstanter Zeit lesen kann. Maßgeblich bleibt die Chain. Ein Dienst hält keinen Zustand, von dem das Netzwerk abhängt – er schlägt einen Wert vor, und real ist nur, was die Chain angenommen hat.

​

Was heute läuft

Volumenbasierte Gebührenstufen. Der Dienst konsumiert die Handelshistorie, die eine Node streamt, summiert das Volumen je Konto und legt nach Zeitplan Snapshots an. Schließt eine Periode, berechnet er für jedes Konto das Volumen im gleitenden Fenster, bildet es über die live von der Chain gelesene Gebührenkonfiguration ab und schreibt geänderte Konten in Stapeln zurück. Mehrere Details in diesem Satz sind tragend:

• Die Stufentabelle wird von der Chain gelesen, nie fest einprogrammiert. Ein Dienst mit eigener Kopie würde weiter die gestrige Staffel anwenden, nachdem das Netzwerk sie geändert hat.
• Verglichen wird mit den Sätzen, nicht mit den Stufenpositionen. Ein Vergleich der Stufenindizes übersieht zwei reale Fälle: Eine Schwelle verschiebt sich, sodass ein unverändertes Konto in einer anderen Stufe landet, oder eine Stufe erhält einen neuen Satz, während ihr Index gleich bleibt. Beides ändert, was ein Konto zahlt; keines ändert seinen Index.
• Den endgültigen Satz löst die Chain auf. Die Transaktion enthält einen Stufenindex; die Ausführung löst ihn gegen die aktuelle Gebührenkonfiguration auf. Ein Stufenindex außerhalb des gültigen Bereichs lässt den gesamten Stapel scheitern, statt teilweise angewendet zu werden.
• Eine Periode gilt erst als angewendet, wenn jeder Stapel festgeschrieben ist. Ein Absturz mitten in der Periode führt zum Replay der ganzen Periode, was gefahrlos ist, weil die Berechnung idempotent ist – dasselbe Fenster liefert dasselbe Ergebnis.

​

Das Fehlermodell

Diese Dienste sitzen zwischen zwei Systemen, die beide zeitweise nicht verfügbar sein werden. Das Design setzt das voraus, statt es als Ausnahme zu behandeln. Ausfälle von Abhängigkeiten – die Datenbank, der Stream der Node, die API der Node – werden mit Backoff wiederholt. Sie beenden den Prozess nicht, denn ein Neustart repariert keine unerreichbare Abhängigkeit; er fügt dem Ausfall nur einen Kaltstart hinzu. Fatal bleibt, was ein Neustart beheben kann oder was ein Betreiber sehen muss: ungültige Konfiguration beim Start, ein nicht bindbarer Health-Endpunkt und Panics. Während eines Ausfalls läuft der Prozess weiter, meldet sich als nicht bereit und zählt Fehler. Das operative Signal lautet deshalb „ist das seit N Minuten nicht bereit“ statt „lebt der Prozess“ – und das ist die nützliche Frage, denn ein lebender Prozess, der seit einer Stunde nichts mehr aufnimmt, ist der eigentliche Vorfall. Auf die Signale eines Orchestrators fährt der Dienst geordnet herunter: Die Arbeit stoppt, Checkpoints werden geschrieben, und der Prozess endet sauber. Ohne das würde jedes Routine-Deployment ein nicht geschriebenes Fenster und ein Replay kosten.

​

Warum sich das Muster verallgemeinern lässt

Der Rückschreibpfad ist generisch. Es gibt Protokolltransaktionen zum Setzen kontobezogener und zum Setzen globaler Konfiguration, und ein Programmdienst ist jeder Prozess, der aus festgeschriebener Historie einen Wert für eine davon berechnet. Die Gebührenstufen sind der einzige laufende Dienst. Anreizprogramme, Empfehlungszuordnung und Kampagnenberechtigung hätten dieselbe Form: eine Fensterberechnung über die Handelshistorie, ein Abgleich gegen das aktuell Angewendete und ein gestapeltes Zurückschreiben. Sie gehörten hierher und nicht in den Kernel, aus demselben Grund wie die Gebührenstufen – die Berechnung ist periodisch und historisch, während die Ausführung die Antwort als Lookup in konstanter Zeit braucht. Keines davon ist gebaut; verallgemeinerbar ist das Muster, nicht die Zusage, dass sie es nutzen werden. Die kommerziellen Konditionen dieser Programme stehen unter Gebühren & Programme. Diese Seite handelt davon, wie das Ergebnis auf die Chain gelangt.

​

Wie es weitergeht