Comment fonctionne l'API des systèmes jackpot

Texte intégral de l'article

💡 18+. Le matériel est d'ingénierie et d'application, sans appel au jeu. Termes : Plate-forme - PAM/portefeuille/caisse/bonus/RG ; RGS - Remote Game Server (noyau des jeux du studio) ; Agrégateur - couche unifiée pour une pluralité de RGS ; JP est un service jackpot.

1) Qu'est-ce qu'un système jackpot et où il se trouve dans l'écosystème

Le jackpot-système est un service distinct (parfois un cluster de services) qui recueille les contributions des paris, gère les pools et les déclencheurs de gains, calcule la distribution des prix et lance les paiements par le biais du circuit de paiement de l'opérateur. Il s'intègre :

avec RGS (rapports de taux/résultats et qualifications), avec plate-forme/portefeuille (prélèvements de cotisations et prêts de gains), avec agrégateur (itinérance de nombreux studios/marques), avec BI/régulateur (télémétrie et reporting).

2) Types de jackpots (et ce qui change dans l'API)

1. Fixe (Fixé) : Montant du prix connu à l'avance. Il n'y a pas de pool dans l'API, seulement la vérification des conditions et le crédit.

2. Progressive (Progressive) : Le pool augmente à partir des cotisations de taux. Il faut des endpoints de contribution et la publication de la taille actuelle.

3. Multi-niveaux (Multi-tier : Mini/Major/Grand) : plusieurs pools parallèles avec différentes cotes et caps.

4. Réseau local vs : pool local - un opérateur/marque ; réseau - total par une multitude d'opérateurs/marques/régions (multitenance et réplication sont critiques).

5. Temporaire/évent : pool avec deadline ou programmé (il faut des minuteries et des tirages automatiques).

3) Invariants monétaires

La source de la vérité sur l'équilibre est le portefeuille/ledger de la plate-forme. JP ne conserve que l'état des pools et des obligations.

Toutes les transactions monétaires sont idempotentes (clés 'jp _ contrib _ id', 'jp _ trigger _ id', 'jp _ payout _ id').

« Paiements perdus/dupliqués » = 0. Les compensations ne sont que des événements (sagas), pas des modifications manuelles de la base de données.

Partagez la contribution (contribution), le déclencheur (trigger) et le paiement (payout) comme transactions indépendantes avec votre propre télémétrie.

4) Contrats API de référence

4. 1 RGS/agrégateur de → JP (contributions et déclencheurs)

'POST/v1/jp/contributions '- compte de la contribution au pool

json
{
"jp_contrib_id": "uuid-1",  "tenant_id": "brand-42",  "pool_id": "grand-eu-01",  "player_id": "p_abc",  "game_id": "studio:slot_777",  "round_id": "r_123",  "bet": {"amount": 2. 00, "currency": "EUR"},  "contrib": {"amount": 0. 02, "currency": "EUR"},  "occurred_at": "2025-10-23T15:12:05Z",  "idempotency_key": "round_r_123"
}

« POST/v1/jp/candidates » - demande de participation/vérification des conditions (facultatif)

Réponse : 'eligible : true/false', poids ou chance, règles.

'POST/v1/jp/triggers '- fixation du fait du déclenchement

json
{
"jp_trigger_id": "uuid-2",  "pool_id": "grand-eu-01",  "reason": "random_hit",  "selector": {"player_id": "p_abc", "round_id": "r_123"},  "occurred_at": "2025-10-23T15:12:06Z",  "idempotency_key": "jp_t_grand_r_123"
}

💡 Note : Dans certains modèles, l'initiateur du déclencheur est JP lui-même (roulette interne), et RGS ne signale que le tour. Les « triggers » sont alors appelés par le JP→platforma et le RGS s'abonne à l'événement.

4. 2 JP plate-forme → (paiements/réserves)

« POST/v1/wallet/reserve » - réserve (optionnelle) pour paiement futur

'POST/v1/wallet/credit '- crédit gagnant au joueur

json
{
"jp_payout_id": "uuid-3",  "tenant_id": "brand-42",  "player_id": "p_abc",  "pool_id": "grand-eu-01",  "amount": {"amount": 500000. 00, "currency": "EUR"},  "meta": {"tax": "withheld=false", "tier": "grand"},  "idempotency_key": "jp_p_grand_r_123"
}

Réponses du platphome : 'credit. ok	failed ', avec des codes de cause (RG/AML, limites de retrait, sanctions, géo-bloc).

4. 3 Publication de l'état du pool (pour les fronts/widgets)

'GET/v1/jp/pools/{ pool _ id} '→ la taille actuelle, seed, cap, nombre de participants, ETA, etc.

'GET/v1/jp/pools '→ la liste des pools par marque/région avec les filtres.

5) Modèle d'événement (Kafka/Pulsar) et schémas

Repères de base :

`jp. contribution. recorded`
`jp. pool. mis à jour '(taille, mises à jour concurrentielles)
`jp. triggered`

`jp. payout. requested	credited	failed`
`wallet. credit. '(miroir pour les sagas)
`rg. limit. hit`, `aml. alert. opened '(si le paiement est bloqué)
`audit. config. changed '(limites, seed, cap, distribution)

Contrats : Avro/JSON Schema + Schema Registry, clés de lot 'tenant _ id', 'pool _ id', 'player _ id'. Le versioning est backward-compatible.

6) Algorithmes de déclenchement (haut niveau)

Probabiliste (p-stable) : pour chaque tour qualifié, nous générons un hit avec une probabilité de « p » (dépendant du pool/type de niveau).

Range (must-drop) : le pool doit tomber à la somme de cap ou à la date limite - nous gardons le random interne dans la gamme [min, max], nous publions cap/ETA.

Syd- et entropy-control : serveur seed + per-round salt ; l'abandon des sièges clients pour les jackpots. Toutes les modifications sont sous WORM Audit.

Honnêteté : le déclencheur ne doit pas dépendre de l'identité spécifique du joueur (à l'exception des règles de géo/licence/qualification). Tout ciblage « personnel » est tabou.

7) SLO et performance

p95 'contribution' <120 ms, p99 <250 ms.

p95 'trigger→credit' <500 ms (sans hop externe).

« Paiements perdus/dupliqués » = 0 (vérifiés par des tests contractuels).

Livraison d'événements en BI ≤ 5 min.

Disponibilité de l'API JP pour les chemins critiques ≥ 99. 95%.

8) Sécurité et conformité

mTLS + signatures (HMAC/EdDSA) sur tous les appels S2S ; jetons à courte durée de vie.

Zero-trust : politiques réseau/mesh, privilèges minimums, segmentation par région.

Audit WORM des modifications des limites, formules, seed/entropy, configues de pools.

GDPR/Data residency/PCI : PII et logs - dans la région ; Tokénisation des champs sensibles ; interdiction des lectures transrégionales.

RG/AML : feux stop synchrones au paiement ; Les décharges SAR/STR sont automatisées.

9) Cohérence et sagas

Contribution ('contribution') - Nous enregistrons dans JP, publions 'jp. contribution. recorded`.

Trigger (« triggered ») : Crée une obligation ; JP lance la saga « payout ».

Paiement ('payout. requested → wallet. credit. ok ') - termine la saga ; pour la faille, les retraits avec déduplication.

Outbox/CDC est le seul moyen de publier des événements ; pas de loggers « de contournement ».

10) Télémétrie et dashboards

Entreprise :

`pool_size`, `contrib_rate`, `avg_contrib_per_bet`, `time_to_drop`, `payouts_count/sum`, `tier_distribution`.

Technique :

p50/p95/p99 по `contribution`, `trigger`, `payout`;
error rate с типами (5xx/4xx/business), retry storms, queue lag;
`wallet. credit` latency/ok-rate; conflit de renouvellement du pool.

Alert :

croissance de 'payout. failed '> X % par marque/région,' pool _ size '> cap - Y % du temps (erreur de configuration), drift entre' pool _ size 'et le montant des contributions de rapprochement> Z ppm.

11) Multiplicité et isolation

Toutes les requêtes et événements sont marqués 'tenant _ id/brand _ id/license/region'.

Les pools locaux/réseaux sont physiquement séparés (DB/cluster) sous différentes licences/régions.

Row-level security (RLS) et masquage dans les vitrines BI.

Clés/secrets individuels et espaces schématiques par marque/région.

12) Intégration avec bonus/tournois

Les contributions n'augmentent pas directement le vader ; la contribution au bonus - vient du taux et non de la contribution.

Les tournois peuvent marquer des points pour « participer à JP » ou « entrer dans les meilleurs dépôts ». Source - événements 'jp. contribution. recorded` и `jp. triggered`.

Règle obligatoire : la mécanique jackpot ne change pas le jeu RTP de base ; Sinon, il faut une certification distincte.

13) Tests et pratiques de chaos

Les tests contractuels sont RGS↔JP↔koshelyok : prise-livraison, retards, out-of-order, rollback.

Tests de charge : tempête de paris et de déclencheurs, mise à l'échelle des workers du pool.

Exercice de chaos : chute de la région JP, porte-monnaie hors ligne, dissynchronisation du temps ; vérification de l'outbox et des dégradations (pause triggers/no new contributions).

14) Chèques-feuilles

Pour studio/RGS

Idempotent 'contribution' et correct 'round _ id '/' bet _ id'.
Aucune publication « contournant » les transactions (outbox/CDC uniquement).
Essais de doublons/déclencheurs répétés/compensations.
Les limites max bet/qualifications sont transférées à JP.

Pour l'opérateur/plateforme

Ledger est la source de la vérité, 'wallet. credit 'avec un grand-père.
Les pieds RG/AML sont traités sur paiement ; rapports SAR/STR.
Dashboards p95 'trigger→credit', taux d'erreur, rapprochements de pools.

Pour le propriétaire de JP

Audit WORM des modifications de formules/seed/limites.
Schémas d'événements dans Registry et versioning.
DR : RPO ≤ 5 min, RTO ≤ 30 min ; des exercices réguliers.
RLS/isolation par marque/licence ; clés/secrets par région.

15) Drapeaux rouges (anti-modèles)

Modifications manuelles de la taille des pools et des paiements dans la base de données.

Manque d'idempotence → prises de crédit.

Publication de télémétrie sans outbox/CDC → contributions/déclencheurs « perdus ».

Mélange des IPI et des données monétaires des différentes régions.

Jackpot qui affecte le RTP du jeu de base sans nouvelle certification.

Pas de porte-monnaie et de pool ; les rapports sont construits selon l'OLTP de combat.

L'API des systèmes jackpot est un contrat monétaire entre le studio, la plate-forme et l'opérateur. Ses fondements sont l'idempotence et les sagas, l'isolement rigide de l'argent, les schémas d'événements clairs, la sécurité et l'audit WORM, l'observation et le SLO. Sur cette conception, les fix/pools progressifs et en réseau sont prévisibles, les paiements restent corrects et les rapports réglementaires et commerciaux sont transparents et fiables.