Ce que « déterministe » signifie réellement au niveau du règlement

Le règlement déterministe est un contrat : le même input doit toujours produire le même output, pour toujours. Étant donné un enregistrement de pari et un enregistrement de résultat officiel, la fonction de règlement renvoie l'une de trois valeurs — settled, void, pending_review. Pas d'horodatages dans la logique, pas d'appels à Math.random(), pas de lectures d'état mutable partagé.

Cela semble évident jusqu'à ce que vous voyiez à quelle fréquence c'est violé en production. Un worker qui lit le cache des cotes pour calculer un remboursement de void n'est pas déterministe. Plus de contexte dans notre anatomie d'intégration.

Le moteur Sporbet Soft impose le déterminisme en traitant le règlement comme une fonction pure de deux arguments — versionnée et rejouable.

Étape un : validation du flux source avant l'exécution

Avant que la fonction de règlement ne s'exécute, le moteur valide le résultat officiel. Le résultat arrive d'un des flux primaires (Sportradar/Betradar, Genius Sports, BetGenius) plus un cross-check optionnel d'un flux secondaire. La couche de validation rejette les résultats qui échouent à l'une des cinq portes. Les scores aberrants sont signalés. Les scores conflictuels entre deux flux sont mis en file pour examen par le trading. Les résultats arrivant avant le seuil de fin officiel (typiquement la 85e minute pour le football) sont retenus.

Ce n'est qu'après qu'un résultat ait franchi les cinq portes qu'il devient un input de règlement. Cela ressemble à du overhead jusqu'à ce que vous vous rappeliez qu'un mauvais événement de flux auto-réglant un marché dans le mauvais sens peut coûter à l'opérateur plus qu'un trimestre de frais de vendor.

Étape deux : recherche de template de marché et sélection de fonction

Chaque marché que le sportsbook offre est soutenu par un template de marché versionné : un document JSON qui capture le nom du marché, ses sélections, ses paramètres et — critique — une référence à la fonction de règlement qui sait comment le régler. Un marché 1X2 temps réglementaire pointe vers settle_1x2_ft. Un handicap asiatique -1.25 pointe vers settle_asian_handicap avec le paramètre de ligne intégré au bet record.

Le template est versionné parce que les définitions de marché changent. Quand une ligue passe de la mort subite à un format de prolongation à deux périodes, le template correspondant ship une nouvelle version. Un pari vieux de cinq ans se règle encore sous les règles qui s'appliquaient le jour où il a été placé.

Étape trois : exécution de la fonction et journalisation rejouable

Avec le résultat validé et le template sélectionné, la fonction de règlement s'exécute. La fonction est un morceau de code quasi-pur — elle prend le pari, le résultat et optionnellement la tentative de règlement précédente, et renvoie la décision plus le montant du paiement. Pas d'I/O, pas de lecture d'horloge, pas de nombre aléatoire.

Chaque exécution écrit un événement de règlement dans le log d'audit append-only. Sporbet Soft couple le log d'audit avec un harnais de replay synthétique qui rejoue chaque règlement chaque nuit contre les dernières versions de fonction et signale toute dérive. En quatre ans d'opération, nous avons attrapé deux vrais bugs de règlement de cette façon avant qu'aucun client ne les remarque.

Sémantique de void et immutabilité des sélections déjà réglées

Le void est l'endroit où les moteurs de règlement naïfs s'écroulent. L'interprétation intuitive — « un match a été annulé, donc inversons tout » — est dangereuse. Si un joueur a placé un accumulateur à quatre jambes et la troisième jambe a déjà été réglée et créditée, annuler rétroactivement le match entier forcerait le moteur à récupérer le crédit d'une wallet qui a depuis été dépensée ou retirée.

La règle Sporbet Soft est explicite : les sélections déjà réglées sont immuables sur void. Quand un match est annulé, le moteur void seulement les sélections qui sont encore pending au moment où le void est traité ; les sélections déjà settled restent settled, et le paiement multi-bet est recalculé en traitant la jambe voidée comme une « jambe void » avec cote effective 1.00.

Selon les règles de finalisation contrôlées par l'opérateur — voir les contrôles de risque opérateur — le void exige un code de raison d'une taxonomie fixe et un ID utilisateur opérateur.

Recalcul multi-bet et réconciliation cashout partiel

Le recalcul multi-bet est l'une des fonctionnalités à plus fort effet de levier dans le moteur. Quand une jambe unique d'un accumulateur se règle, le moteur n'attend pas que le pari entier soit prêt — il recalcule incrémentalement l'exposition du pari et la responsabilité ouverte de l'opérateur.

Le cashout partiel ajoute un deuxième axe. Un joueur qui retire 40 % d'un accumulateur à quatre jambes après deux jambes gagnées laisse 60 % du pari actif ; le moteur doit réconcilier le cashout 40 % contre la wallet, marquer 60 % de la mise originale comme encore-à-risque et continuer à recalculer le multi.

Le défi d'ingénierie n'est pas les maths, c'est la concurrence. Sporbet Soft utilise des clés d'idempotence dérivées de l'ID de pari, l'ID de jambe et le compteur de tentative — voir notre architecture de latence des cotes.

Résolution de litige : le lien d'audit-trail est la réponse

Un flux de résolution de litige qui exige un message Slack du trading floor échelonne comme un message Slack — pas du tout. Le modèle Sporbet Soft est que chaque litige commence et termine au lien d'audit-trail du pari dans le partner panel. Le lien fait apparaître sur un écran : l'enregistrement du pari, le snapshot de wallet du joueur, le résultat de flux validé, la version du template, la version de la fonction, la décision, le paiement, chaque événement de cashout, chaque événement de void et un bouton de replay en un clic.

En quatre ans d'opération, le temps moyen de résolution sur un litige de règlement à Sporbet Soft est sous deux minutes ; le benchmark industrie comparable sur des plateformes tier-1 avec règlement non-rejouable est plus proche de deux jours.

Ces détails sont ce que l'iframe cache à vos ingénieurs pour qu'ils puissent passer du temps sur des surfaces de croissance.