De courtes notes sur des décisions de conception de notre propre plateforme. Elles décrivent ce que fait le code aujourd’hui, pas des promesses marketing.
Pourquoi chaque appel au portefeuille porte une clé d’idempotence
Les réseaux répètent les requêtes. Un portefeuille incapable de reconnaître une répétition paiera deux fois.
Un fournisseur de casino appelle un portefeuille lorsqu’un joueur mise ou gagne. Si l’appel expire, le fournisseur ne peut pas savoir si le portefeuille l’a appliqué : il renvoie donc le même appel. Sans protection, la seconde livraison débite ou crédite une seconde fois.
Notre registre traite donc l’identifiant de transaction comme une clé unique par opérateur. Un identifiant répété avec un contenu identique renvoie le résultat d’origine en le signalant comme rejoué. Le même identifiant avec un contenu différent est refusé. Le registre est en ajout seul et garanti par la base de données : une correction est une nouvelle écriture compensatoire, jamais une modification.
La leçon pratique pour toute intégration : choisissez la clé avant d’écrire l’appel, et testez la répétition, pas seulement la première livraison.
Gérer un appel de portefeuille arrivé à expiration
Un délai dépassé n’est pas un échec. C’est une réponse que vous n’avez pas encore.
Lorsque la plateforme appelle un portefeuille détenu par l’opérateur et que rien ne revient, l’argent a pu bouger ou non. Traiter le délai dépassé comme un échec peut laisser un joueur débité sans mise enregistrée ; le traiter comme un succès peut produire l’inverse.
Nous consignons l’appel comme inconnu, le rejouons avec le même identifiant de transaction afin que l’opérateur puisse répondre de façon idempotente, et lançons une tâche de reprise. Une écriture de registre n’est créée que lorsque le résultat est connu.
Le coût est un peu d’état supplémentaire et une tâche de fond. L’avantage est qu’un problème de réseau ne modifie jamais silencieusement un solde.
L’isolation des locataires est un test, pas une promesse
Un opérateur ne doit jamais voir les joueurs, transactions ou clés d’un autre.
Dans une plateforme multi-locataires, un filtre oublié dans une seule requête suffit à divulguer les données d’un autre client. Nous appliquons la portée du locataire dans la couche de données, autorisons les requêtes avant que les enregistrements soient chargés, et vérifions le résultat par des tests négatifs qui tentent de franchir la frontière.
L’ordre compte : si une route charge un enregistrement avant de vérifier la permission, la différence entre « introuvable » et « interdit » révèle quels identifiants existent. Vérifier d’abord supprime ce signal.
Pour une plateforme qui manipule l’argent des opérateurs, nous préférons un test qui échoue à une phrase rassurante.
