Was 'deterministisch' auf der Settlement-Schicht wirklich bedeutet

Deterministisches Settlement ist ein Vertrag: derselbe Input muss immer denselben Output produzieren — für immer. Gegeben einen Bet-Record und einen offiziellen Result-Record gibt die Settlement-Funktion einen von drei Werten zurück — settled, void, pending_review. Keine Zeitstempel in der Logik, keine Aufrufe von Math.random(), keine Reads von shared mutable State.

Das klingt offensichtlich, bis Sie sehen, wie oft es in der Produktion verletzt wird. Ein Worker, der den Quoten-Cache liest, um eine Void-Rückerstattung zu berechnen, ist nicht deterministisch. Mehr Kontext in unserer Integrations-Anatomie.

Der Sporbet-Soft-Motor erzwingt Determinismus, indem er Settlement als reine Funktion zweier Argumente behandelt — versioniert und replayable.

Schritt eins: Quelldaten-Validierung vor der Funktion

Bevor die Settlement-Funktion ausgeführt wird, validiert der Motor das offizielle Ergebnis. Das Ergebnis kommt von einem der primären Feeds (Sportradar/Betradar, Genius Sports, BetGenius) plus optionalem Second-Feed-Cross-Check. Die Validierungsschicht lehnt Ergebnisse ab, die eine von fünf Gates nicht bestehen. Ausreißer-Scores werden markiert. Widersprüchliche Scores zwischen zwei Feeds werden zur Trading-Review eingereiht. Ergebnisse vor dem offiziellen Endzeit-Threshold (für Fußball typischerweise 85 Minuten) werden zurückgehalten.

Erst nachdem ein Ergebnis alle fünf Gates passiert hat, wird es zum Settlement-Input. Das klingt nach Overhead, bis Sie sich daran erinnern, dass ein schlechtes Feed-Event, das einen Markt auf der falschen Seite auto-settled, den Operator mehr kosten kann als eine Quartals-Vendor-Gebühr.

Schritt zwei: Market-Template-Lookup und Funktionsauswahl

Jeder Markt im Sportsbook wird durch ein versioniertes Market-Template gestützt: ein JSON-Dokument, das den Namen des Marktes, seine Selektionen, Parameter und — kritisch — eine Referenz auf die Settlement-Funktion erfasst, die ihn settled. Ein 1X2-Full-Time-Markt zeigt auf settle_1x2_ft. Asian Handicap -1.25 zeigt auf settle_asian_handicap mit dem in den Bet-Record eingebackenen Line-Parameter.

Das Template ist versioniert, weil Marktdefinitionen sich ändern. Wenn eine Liga von Sudden-Death-Overtime auf Zwei-Perioden-Overtime wechselt, shippt das entsprechende Template eine neue Version. Eine fünf Jahre alte Wette settled immer noch unter den Regeln, die am Tag ihres Placements galten.

Schritt drei: Funktionsausführung und Replay-Logging

Mit dem validierten Ergebnis und dem ausgewählten Template läuft die Settlement-Funktion. Die Funktion ist ein semi-reines Code-Stück — nimmt die Wette, das Ergebnis und optional den vorherigen Settlement-Versuch und gibt die Settlement-Entscheidung plus den Payout-Betrag zurück. Kein I/O, keine Uhr-Reads, keine Zufallszahlen.

Jede Ausführung schreibt ein Settlement-Event ins append-only Audit-Log. Sporbet Soft koppelt das Audit-Log mit einem synthetischen Replay-Harness, der jedes Settlement nächtlich gegen die neuesten Funktionsversionen wiederholt und Drift flaggt. In vier Jahren Betrieb haben wir auf diese Weise zwei echte Settlement-Bugs erwischt, bevor irgendein Kunde sie bemerkt hat.

Void-Semantik und die Immutabilität bereits settled Selektionen

Void ist der Ort, an dem naive Settlement-Motoren auseinanderfallen. Die intuitive Interpretation — 'ein Spiel wurde annulliert, also lasst uns alles rückgängig machen' — ist gefährlich. Wenn ein Spieler einen Vierfach-Accumulator platziert hat und das dritte Bein bereits settled und gutgeschrieben wurde, würde das retroaktive Annullieren des gesamten Spiels den Motor zwingen, Credit aus einer Wallet zurückzuholen, die seitdem ausgegeben oder abgehoben wurde.

Die Sporbet-Soft-Regel ist explizit: Bereits settled Selektionen sind void-immutable. Wenn ein Spiel annulliert wird, void der Motor nur die Selektionen, die in dem Moment noch pending sind. Selektionen, die bereits settled sind, bleiben settled, und der Multi-Bet-Payout wird neu berechnet, wobei das voidete Bein als 'Void-Bein' mit effektiver Quote 1.00 behandelt wird.

Per den operator-gesteuerten Match-Finalisierungs-Regeln — siehe operator-grade Risikokontrollen — erfordert Void einen Reason-Code aus einer fixen Taxonomie und eine Operator-User-ID.

Multi-Bet-Recompute und partielle Cashout-Reconciliation

Multi-Bet-Recompute ist eines der hochwertigeren Features im Motor. Wenn ein einzelnes Bein eines Accumulators settled, wartet der Motor nicht, bis die gesamte Wette bereit ist — er berechnet die Exposure der Wette und die offene Liability des Operators inkrementell neu. Wenn das Bein verliert, wird die Wette sofort als verloren settled.

Partial Cashout fügt eine zweite Achse hinzu. Ein Spieler, der 40 % eines Vier-Bein-Accumulators nach zwei gewonnenen Beinen auscashed, lässt 60 % der Wette aktiv; der Motor muss den 40 %-Cashout gegen die Wallet abstimmen, 60 % des ursprünglichen Stakes als noch-im-Risiko markieren und das Multi weiter neu berechnen.

Die Engineering-Herausforderung ist nicht die Mathematik, sondern die Concurrency. Sporbet Soft verwendet Idempotency-Keys aus Bet-ID, Leg-ID und Settlement-Attempt-Counter — siehe unsere Quoten-Latenz-Architektur.