L'architecture multimarque du casino : services partagés et isolation

Texte intégral de l'article

💡 18+. Matériel éducatif. Pas un appel au jeu. L'accent est mis sur l'ingénierie et la conformité des plates-formes iGaming.

1) Le défi de la plate-forme multimarque

Un « squelette » technologique sert plusieurs marques/licences/géo. L'objectif est le maximum de la réunion du noyau (vitesse, coût) avec une isolation stricte des risques et des données (argent, PII, comptabilité).

Choix clé : multi-tenant (instances communes, « locataires » au sein d'un même service) ou multi-instance (instances individuelles/OBD/clusters par marque ou région). En pratique, on utilise un hybride.

2) Couches et limites (schéma de référence)

Edge / Governance

API-gateway, WAF/bot-protection, géo-filtres, tarifs, service-mesh.

Tenant/brand resolver : métadonnées de la marque (licence, géo, monnaie, drapeaux).

Domain Core (par service)

PAM (comptes, sessions, 2FA) - multi-tenant avec séparation rigide des tenant_id.

Wallet/Ledger (comptabilité) - plus souvent multi-instance per license/region.

Cashier/PSP Orchestration - Piplines/clés séparées par marque/région.

KYC/AML - fournisseurs connectables par géo, règles au niveau tenant.

Bonus Engine/Tournements/Jackpots - Services partagés avec isolation des règles.

Game Gateway est une passerelle commune vers les fournisseurs avec mapping fich/devises par marque.

Affiliates/Commission - mathématiques générales, espaces de traçage séparés.

RG - limites et statuts au niveau de la marque/juridiction, feux d'arrêt synchrones.

Conformité/Reporting - vitrines et déchargement par marque/licence/région.

CMS/Front - outils communs + per-brand thèmes/navigation.

Data & Observability

Bus d'événements (Kafka/Pulsar) avec les clés 'tenant _ id/brand _ id'.

OLTP pour le service, OLAP vitrines avec isolation row-level rigide par marque.

Métriques/trajets/logs avec étiquettes de tenant obligatoires ; SIEM/SOAR.

3) Où partager et où isoler

3. 1 Services communs (économie et rapidité)

Game Gateway : intégrations uniques avec les studios, drapeaux fich per brand.

Bonus/Tournament Engine : concepteur commun, mais « sandbox » et limites par marque.

Affiliates/Tracking : une plate-forme unique, séparée par les domaines/ID/post-back.

KYC/Screening Orchestrator : bus partagé, différents fournisseurs par géo.

CMS/Front toolkit : thèmes/localisation/widgets ; un front dégonflé séparé du noyau.

BI/ETL : Piplines générales, vitrines séparées et droits.

3. 2 Isolement sévère (argent, droit, données personnelles)

Ledger/Wallet : OBD/instances individuelles pour la licence/région (souvent même un cluster séparé).

Cashier/PSP : clés, merchants, routage et limites par marque/région.

PII/Résidence : les données des utilisateurs sont stockées dans la région ; interdiction des demandes intersectorielles.

Conformité/Reporting : déchargement réglementaire strictement par marque/licence.

RG/AML : les feux stop sont appliqués « sur place », sans bille intertenante.

4) Modèles de multitenance des données

1. Schema-per-tenant : une base de données, des schémas distincts. C'est plus difficile à mettre à l'échelle.

2. DB-per-tenant : bases de données individuelles (ou clusters) par marque/région. C'est plus cher, mais plus sûr.

3. Table-partitioning by tenant : grandes tables avec RLS/masquage rigide ; convient à la télémétrie/logs.

4. Storage-per-jurisme : résidence physique (EU, UK, BR...), accès interrégional interdit sur le réseau/ACL.

Pour Ledger, une couche de service distincte est généralement choisie DB-per-license/region +.

5) Circuit monétaire : invariants et événements

L'atomicité et l'idempotence des commandes ('wallet. debit/credit/settle ') est un contrat clé.

Outbox/CDC : publication d'événements synchronisés sur une transaction ; pas de « magie manuelle ».

Sagas : dépôt/cache/bonus - uniquement par orchestration, compensation par des événements individuels.

Jackpot-portefeuille séparé et contributions transparentes par marque/pool.

SLO pour le noyau (minimum) :

p95 porte-monnaie <150 ms ; settlements perdus/dupliqués = 0.
Autorisation Cashier <3 s ; succès du dépôt ≥ 85 % sur la cible géo.
Livraison d'événements en BI ≤ 5 min.

6) Orchestration de paiement en multimarque

Pipline per brand/market : différents PSP, merchants, limites, politiques 3-DS.

Cascade : échec → fallback sans perte de panier.

FinOps : itinéraires par coût/conversion ; les rapports de rapprochement par marque sont quotidiens.

Anti-frod : velocity, liens graphiques cartes/appareils au sein de la marque et de la holding (avec corrélation croisée prudente).

7) Jeu responsable et conformité

Limites RG (dépôt/perte/temps/taux) - configurées par la marque/juridiction, appliquées de manière synchrone au taux.

L'auto-exclusion et les chèques réels respectent les frontières de la marque et la loi de la région.

AML/KYC - Sanctionnaires/RER/source de fonds ; SAR/STR par marque.

Rapport - automatisé ; Excel manuel est interdit en tant que processus.

8) Observabilité et accès

Trace-ID de bout en bout + balises 'tenant _ id/brand _ id/license'.

RBAC/ABAC : les rôles "финансы/риск/саппорт/маркетинг/комплаенс" - l'accès seulement vers своему à la marque.

Audit WORM : logiques immuables des actions Crète, politique des « quatre yeux ».

Secrets/clés : Vault/HSM, segmentation des clés par marque/région, rotation.

9) Topologies du dépliant

Single Cluster, Multi-Tenant Services

Démarrage rapide, économies denses. Nécessite un RLS mature, une isolation des ressources et des limites.

Regional Clusters + Shared Integrations

La passerelle de jeu et une partie des services communs se chargent, l'argent/PII - régional. Équilibre des coûts et de la conformité.

Per-Brand/License Stacks

Isolation complète (marques VIP, risques élevés). Cher, mais minimum rayon blast.

Souvent combinés : une « couche » commune d'intégrations et d'outils + argent isolé/PII.

10) Sur les données et les catalogues

Data contracts: Avro/JSON Schema + Registry; versions sémantiques.

Governance : annuaire des champs, propriétaires, vitrine SLA, ligne d'origine (lineage).

RLS/Masking : règles au niveau du stockage et BI ; accès au PII - par application et token temporel.

Late arrivals/dedup : modèles upsert résistants en OLAP.

11) Marketing, CMS et affiliations

Feature Flags per brand : sortie promo/tome/mécanique sans effets croisés.

Catalogues de contenu : ID unique des fournisseurs/jeux, mapping de disponibilité sur la marque/le marché.

Affiliations : domaines séparés/UTM/PB-ID ; anti-fred sur les sous-partenaires.

Conformité aux plates-formes (YouTube/Twitch) : marquage des annonces/affiliations par marque.

12) Métriques de maturité de l'architecture multimarque

1. Isolement de l'argent : EDR/instances individuelles pour la licence/région ; Zéro édition manuelle.

2. Résidence de données : techniquement assurée (ACL/politiques de réseau), validée par des exercices.

3. Evénement : outbox/CDC partout ; les flux atteignent BI ≤ 5 min.

4. Paiements : la cascade PSP est active ; les rapports de rapprochement sont automatisés.

5. RG/AML : les feux stop sont appliqués de manière synchrone ; un rapport sans étapes manuelles.

6. Observability : toutes les métriques/logs/trajets sont marqués avec la marque/tenant ; dashboards SLO par services et marques.

7. Accès : RBAC/ABAC et « quatre yeux » sur les opérations en Crète, audit WORM.

8. Plan DR : RPO ≤ 5 min, RTO ≤ 30 min ; exercices réguliers pour chaque région.

13) Chèque de l'architecte (avant le lancement de la marque)

Attribué à 'brand _ id/tenant _ id', avec clés/secrets et limites.
Ledger/Wallet est une base de données/cluster dédiée (si une licence est requise).
Cashier - comptes et itinéraires merchants ; opérations de test et de rapprochement.
RG/AML/KYC - fournisseurs, règlements, feux stop ; scénarios de test.
Game Gateway - mapping des fournisseurs/devises/restrictions ; chèque santé.
Bonus/Tournament est un bac à sable et un audit des règles.
Affiliates est un espace de boo, post-back, anti-frod.
CMS/Front - thème, localisation, fichflags ; vérification des limites géographiques.
BI/Rapports - vitrines, accès, décharges réglementaires.
Observability - dashboards SLO et alerties par marque/région.

14) Drapeaux rouges (ce qui brise le multimarque)

Une base de données unique « pour tous » sans RLS/masquage et sans Ledger séparé.

Édition manuelle des soldes, bonus et limites.

Clés de merchant communes PSP pour différentes marques/régions.

Publier les événements « passé » les transactions de domaine (pas de outbox/CDC).

BI/rapports sur les tables OLTP de combat.

L'absence de géo-isolement PII et d'exercices DR.

Les règles RG/AML sont déchirées entre les marques sans tenir compte de la loi locale.

Il n'y a pas d'étiquettes tenant/marque dans les logs et les métriques - les enquêtes se transforment en chaos.

15) Résultat

L'architecture multimarque est l'équilibre entre le commun et le séparé. Les intégrations, les outils et les développements communs accélèrent le développement ; l'argent isolé, les paiements, les IPI et la déclaration maintiennent la conformité et réduisent les risques. Une plate-forme réussie repose sur trois principes :

1. Intégrité monétaire et isolement (Ledger/Cashier per license/region, idempotence, sagas).

2. Evénement et observabilité (bus, contrats, étiquettes de marque/tenant, SLO).

3. Résidence juridique et accès au minimum (RBAC/ABAC, audit WORM, KMS/Vault).

Une telle base permet de mettre à l'échelle un portefeuille de marques sans croissance exponentielle de complexité - rapide, sûre et prévisible.