Module tournois et missions : événements, classements, récompenses

1) Objectifs commerciaux et types d'activités

Objectifs : augmentation de la rétention (D1/D7), ARPPU, augmentation de la profondeur des sessions, promotion de nouveaux jeux et marchés.

Formats :

Tournois : pour le total des points/gains/multiplicateurs, sprints (30-60 min), jour, saison.
Missions/quêtes : séquences de tâches (jouez N spins, gagnez X, essayez Y fournisseur), avec des progrès et des récompenses par étapes.
Liderboards : global, par marchés/jeux/paris, privé (amis/VIP).
Jackpots/classements des studios : « top fournisseurs de la semaine », « chasse au multiplicateur ».

KPI : participation ≥ 12-25 % du public actif, part des revenus de la promo 10-20 %, plaintes <0. 5 % des participants, prix émis ≤ plan.

2) Architecture et flux de données

Composants

1. Events Gateway → la réception d'événements de jeu (spin, bet, win, round_end) à partir de game-gateway/fournisseurs.

2. Rules Engine → joue les événements sur les règles des tournois/missions, attribue des points (idempotent).

3. Le Leader Board Service → agrège les lunettes, stocke les tops/tranches, prend en charge le tri et le tie-break.

4. Progress Service (mission) → l'état des tâches/étapes, la délivrance des récompenses intermédiaires.

5. Rewards Service → un paiement sécurisé (cash/bonus/fs/points).

6. Admin/Studio UI → créer, planifier, prévisualiser l'économie, simuler.

7. Realtime/WS → publication des mises à jour du leader, des progrès, des notifications.

8. Anti-Abuse → limites, signaux de risque, intégration avec antifrood/bot manager.

9. Storage/Cache → KV/Redis pour les hauts chauds, OLTP pour les faits, DWH pour l'analyse.

Flux (e2e)

`game_event → gateway → rules_match → points → leaderboard_update → (progress_update) → notify → rewards_at_close → wallet_postings`

3) Modèle d'événement (minimum de champs)

json
{
"event_id": "e_9f2",  "ts": "2025-10-23T17:41:26Z",  "user_id": "u_123",  "market": "DE",  "brand": "X",  "game": {"id":"g_77", "provider":"PragmaticPlay", "type":"slot"},  "bet": {"amount_minor": 100, "currency":"EUR"},  "win": {"amount_minor": 250, "multiplier":2. 5},  "round": {"id":"r_abc","status":"ended"},  "device": {"platform":"mobile","asn":"mno"},  "trace_id": "t_…"
}

Transport - Kafka/HTTP, traitement idempotent (dedupe par 'event _ id'), signature fournisseur/passerelle de jeu (HMAC).

4) Règles de tournois et concepteur de tâches

Schéma déclaratif (exemple YAML) :

yaml id: t_october_sprint window: {start: 2025-10-25T18:00Z, end: 2025-10-25T19:00Z, tz: Europe/Kyiv}
scope:
markets: [DE, SE]
providers: [PragmaticPlay, Hacksaw]
scoring:
formula: "points = min(win. amount/bet. amount, 50) 100" # par multiplicateur de min_bet_minor : 50 eligible_games : ["g _"]
leaderboard:
type : "best_n_rounds" # résumer les meilleurs N rounds n : 20 tiebreaker : ["highest _ single _ multiplier" ", earliest _ finish _ ts']
rewards:
pool: {currency: EUR, total_minor: 1000000}
distribution : « ladder » # escalier, top 100 anti_abuse :
min_round_duration_ms: 800 max_rps_per_user: 0. 5 exclude_asn_categories: ["hosting", "proxy"]

Missions (DSL) :

yaml mission_id: m_halloween steps:
- id: s1 goal: {type: "spin_count", game_type: "slot", count: 50}
reward: {type: "freespins", value: 10, game: "g_66"}
- id: s2 goal: {type: "win_multiplier", min: 10}
reward: {type:"bonus", amount_minor: 500}
completion_reward: {type: "points", amount: 1000}

5) Classements et algorithmes de comptage

Modèles de base

Somme des points : linéaire/logarithmique/avec capuche par round.

Les meilleurs N rounds : réduit le « pay-to-grind », maintient la dynamique « sprint ».

Multiplicateur maximum (xWin) : normalise les devises et les taux.

MMR/système de notation : ELO pour PvP/tables de concurrence amicale.

Fonds-breaks

1. 'highest _ single _ multiplier' → 2) 'fewest _ rounds' → 3) 'earliest _ finish _ ts' → 4)' user _ id 'lexicographiquement (fixe dans les règles).

Performances

Stockez le top K (par exemple, 10k) dans le Redis Sorted Set 'ZADD key score membre'.

Pour les « meilleurs N rounds » : stockez les min-heap des derniers N meilleurs par utilisateur et montant, mettez à jour « à la volée ».

Snapshot périodiquement (toutes les 30-60 s) dans OLTP/objet.

6) Récompenses et paiements

Types de récompenses : cash/bonus/free spins/points/objets/billets.

Règles :

Extradition seulement après finalisation (fenêtre de recours 5-10 min).
Tous les paiements sont par le biais de Rewards Service → Wallet (ledger) : double-entrée, idempotence par "reward _ id'.
Pour les phases intermédiaires des missions - l'émission de récompenses « douces » (FS/points), cash - à la fin de la chaîne.
KUS/jeu responsable : lors du blocage d'un compte - rétention/gel du prix jusqu'à la vérification.

Schémas de distribution :

Ladder fixe : étapes prédéfinies (1ère 30 %, 2ème 20 %,...).
Proportional : part du pool par lunettes, mais de cap par place.
Ticket-based : les missions donnent des « tickets », un tirage au sort (RNG transparent).

7) Anti-abysse, honnêteté et conformité

Filtres eligibility : min pari/durée du tour, exclusion « 0-bet », re-fractures répétées, « micro-paris » dans le convoyeur.

Les canots-signaux : headless-UA, la périodicité anormale, anomalement stable RPS, proxy-ASN → caché la tchellendji/congélation des points.

Dédup/idempotence : événements par 'event _ id', facturation par 'score _ id'.

Piste d'audit : photos du leader, RNG seed (pour le tirage au sort), version des règles, hachage des calculs.

Légal : règles/restrictions de marché, âge, auto-exclusion.

8) L'économie des tournois

Budget guardrails : limite supérieure du pool + dynamique « safety valve » (réduction des primes intermédiaires en cas de surchauffe).

Élasticité : décalage des récompenses en points/FS au lieu de cash pour maintenir la marge.

Taux de rentabilité : prix/recettes du segment des jeux de tournoi ; ciblage 8-15 %.

Simulateur dans l'admin : exécution d'événements historiques → prévision de paiement/participation.

9) contrats API (simplifié)

Obtenir des tournois/missions actifs

http
GET /v1/contests? market=DE&brand=X
→ 200 [{"id":"t_october_sprint","start":"…","end":"…","type":"xwin","status":"live"}]

Événement du jeu (ingest)

http
POST /v1/events
{"event_id":"e_9f2", "...": "..."}
→ 202 {"accepted":true}

Liderbord (top K et position utilisateur)

http
GET /v1/leaderboards/t_october_sprint? top=100&me=u_123
→ 200 {"top":[{"pos":1,"user":"u_9","score":18400},...],    "me":{"pos":342,"score":5600,"delta":+200}}

Progrès de la mission et récompense

http
GET /v1/missions/m_halloween/progress? user=u_123
→ 200 {"steps":[{"id":"s1","done":true},{"id":"s2","done":false}],"reward_ready":true}

POST /v1/rewards/claim
{"context":"mission","id":"m_halloween","step":"s1"}
→ 201 {"status":"granted","reward_id":"rw_77"}

10) Stockage et mise à l'échelle

Chemin chaud : Redis (Sorted Sets/Hash) pour les hauts et les progrès ; TTL pour les clés "bruyantes", chardonnez par "contest _ id'.

Vérité : OLTP (Postgres/MySQL) - faits de points/progrès/paiement (snapshots WORM).

Files d'attente : Kafka - flux d'événements ; Groupes consommateurs par région/marque.

Caches : court TTL 1-5 s ; stale-while-revalidate pour les tops publics (via CDN).

WebSocket : cluster/pool séparé sous realtime, newsletter et rate-limit.

11) Observation et contrôle de la qualité

SLI/SLO:

`leaderboard_update_latency_p95 ≤ 250мс`
`events_ingest_success ≥ 99. 9%`
`rewards_grant_success ≥ 99. 9%`
`ws_push_rtt_p95 ≤ 120мс`
plaintes pour injustice <0. 5 % des participants.

Métriques :

taux d'événements/participants, joueurs uniques, répartition par taux/jeux, multiplicateur moyen ; 'grant _ errors', 'dedupe _ hits'.
Tracés : ingest → rules → score → LB update → reward ; les balises 'contest _ id', 'rule _ id'.
Logs : JSON avec 'trace _ id', interdiction PII ; WORM pour l'audit.

12) Incidents et runbook 'et (abrégé)

A. Retard du leader (lag> 2c)

Actions : augmenter les consommateurs de Kafka, réduire le lot « clé chaude » (réparation), activer la mise à jour de batching.

Temporaire : geler les animations realtime, afficher « ~ 1-2s de retard ».

B. Erreurs dans l'attribution des bourses

Actions : arrêter les nouveaux 'grant', vérifier avec le snapshot, rejouer 'grant' idempotent ; statut d'apdate dans le lobby.

C. Éclair d'abysse (proxy ASN)

Actions : renforcer l'eligibility, activer le challenge invisible, temporairement ne pas prendre en compte les points pour les sessions douteuses, post-vérification.

13) UX et localisation

Temps réel : indicateur « live », delta lisse des lunettes, position et distance jusqu'à l'endroit suivant.

Règles transparentes : accès à la formule/tie-break/restrictions.

Les notifications : "il y avait 5 minutes", "toi à top 50", "la récompense est accessible".

Localisation/textes juridiques : par marché, fuseaux horaires (Europe/Kyiv et localités des participants).

14) Sécurité et vie privée

Les pseudonymes des joueurs sur les sommets publics ; masquer le PII par défaut.

Signatures de webhooks/événements, mTLS ; protection contre le « cache poison » sur edge.

API rate-limit, protection contre le cache basting, contrôle 'idempotency _ key'.

RGPD : durée de conservation des événements, droit de suppression (anonymisation) sans altération de l'audit.

15) Tests et simulations

Une réplique d'événements historiques pour valider les règles et l'économie.

Charge : bursts 30-120 avec avant le départ ; soak 2-4 heures

Property-based : invariants (« montant des récompenses accordées ≤ budget », « tie-break déterministe »).

A/B : différentes formules de lunettes, profondeur de l'échelle, format des missions.

16) Chèque-liste de production-prêt

Règles déclaratives (versions, signatures), simulateur d'économie.
Idempotence : 'event _ id', 'score _ id', 'reward _ id' ; Inbox/Outbox.
Les tie-breaks sont fixes dans les règles, le déterminisme du tri.
Liderbords : top K dans Redis + snapshots ; anti-tempête (jitter, coalescing).
Anti-abuse : eligibility, bots/ASN, limites velocity.
Rewards → Wallet par double entrée ; KYC-chèque avant cash.
Observabilité : SLI/SLO, dashboards, alertes ; Audit WORM.
DR/Failover : multi-AZ, backups/restore, « freeze & finalize » script.
Localisation, licences, règles publiques et consentement.
Runbook 'et sur lag/erreurs de grant/surtension de bots, modèles de communication.

Résumé

Le module réussi des tournois et des missions est un bus d'événements + règles déterministes + leaders rapides + paiements sécurisés. Ajoutez des tie-breaks rigoureux, un anti-abyse, un simulateur d'économie et une observabilité SLO, gardez toutes les opérations idempotentes et auditées - et vous obtiendrez un outil qui augmente l'engagement et les revenus sans controverse avec les joueurs, les régulateurs et l'équipe de soutien.