Event-Streaming et données en temps réel

(Section : Technologie et infrastructure)

Résumé succinct

Event-Streaming est le traitement et la livraison des événements au moment de leur apparition. Pour iGaming, cela signifie une réponse instantanée aux paris, aux dépôts, aux signaux anti-fraud, aux limites du jeu responsable, aux tables de tournoi et aux offers personnels. Briques de base : bus d'événements (Kafka/Pulsar), moteur de streaming (Flink/ksqlDB/Spark Structured Streaming), CDC à partir d'OBD transactionnelles (Debezium), Feature Store pour l'analyse en ligne ML et en temps réel (représentations matérialisées, OLAP).

Où c'est critique dans iGaming

Anti-fraud & risque : numérisation des transactions en <100-300 ms, corrélation des schémas comportementaux, blocage et escalade.
Jeu responsable : contrôle des limites, taux de perte, comportement anormal - alertes et auto-contraintes en temps réel.
Paiements : portes d'état, webhooks PSP, smart-retry, projections de bilan, SLA « time-to-wallet ».
Events de jeu : calcul des leaders du tournoi (fenêtres de sliding), tours de jeux en direct, flux temps réel pour le CRM/marketing.
La personnalisation : features en ligne (RFM, propensity) → déclencheurs les campagnes, push/email pendant des secondes.
Analyse en ligne : p95/p99 latency, conversion des étapes d'entonnoir, signaux de santé de la plate-forme.

Modèles architecturaux

Lambda vs Kappa

Lambda : batch (DWH/ETL) + streaming (temps plein). En plus, la flexibilité et le bach « bon marché » ; le négatif est une double logique.
Kappa : tout est comme un flux du magazine (Kafka). En plus, un code unique, un jeu d'événements ; moins - les exigences d'infrastructure sont plus strictes.

Pratique : pour les contours critiques du temps réel - Kappa ; pour le reporting/ML-learning - circuit de batch supplémentaire.

Convoyeur d'événements (référence)

1. Fabricants : Les services de paris/paiements publient des événements de domaine (outbox → Kafka).
2. Bus : Kafka avec des lots par clé ('player_id', 'bet_id').
3. CDC : Debezium tire les changements de l'OLTP (balances, limites) vers le stream.
4. Traitement en continu : Flink/ksqlDB/Spark - agrégations, fenêtres, CEP, join.
5. Projections : tables matérialisées (Kafka Streams state store/ksqlDB tables/Redis), OLAP (ClickHouse/Druid).
6. Consommateurs : anti-fraud, CRM, notifications, dashboards, workflow déclencheur.

Contrats et schémas de données

Avro/Protobuf + Schema Registry : contrats rigoureux, migration backward-compatible.
Versioning : 'domain. event. v{n}`; interdire les changements cassants.
PII : Tokenization/cryptage, masquage, limitation de la purpose (RGPD).

Sémantique de livraison et idempotence

At-least-once est une norme de facto (doublons possibles) → obligatoire idempotent-handling.
Exactly-once en streaming : les vendeurs transactionnels Kafka + EOS à Flink/Streams ; plus cher, appliquer ponctuellement (argent/solde).
Outbox + CDC : source unique de vérité du service OBD, protection contre le double enregistrement.
Dedup : clé ('idempotency_key'), table de déduplication avec TTL, upsert/merge.

Fenêtres temporelles et données « tardives »

• Tumbling - slots fixes (par exemple, minute de tour).
• Hopping - glissant avec pas (par exemple, fenêtre de 5 min avec pas de 1 min).
• Session - par inactivité (session du joueur).
• Watermarks : traitement par event-time, tolérance des « tardifs » (lateness), évacuation vers DLQ/side-output.
• PPE (Complex Event Processing) : motifs « A puis B en 3 min », « N événements en M secondes », « annulation/compensation ».

État et mise à l'échelle

Opérateurs Stateful : les agrégations/joyaux gardent l'état (RocksDB state backend).
Changelog topics : fiabilité et restauration de l'état.
Backpressure : réglage automatique de la vitesse, limites de sink/外 du système.
La distribution des clés : les clés chaudes (heavy hitters) → key-salting, skew mitigation.

Surveillance et SLO

SLO du flux : p99 end-to-end latency (par exemple, ≤ 2), admissible consumer lag, l'accessibilité ≥ 99. 9%.
Métriques : throughput, lag par lot, watermark delay, drop/late ratio, backpressure, busy time opérateurs, GC/JVM.
Alert : croissance du DLQ, retard du watermark, échecs des chekpoints EOS, dispersion des features en ligne/hors ligne.
Tracing : Corelation ID ('trace_id', 'message_id') à travers le fournisseur-stream-consumer.

Sécurité et conformité

TLS/MTLS, ACL/RBAC sur tops/tables, segmentation des domaines sensibles (paiements/CUS).
Cryptage PII en transit/disque ; secrets dans Vault/SOPS.
Rétention de données et localisation : stockage par région (UE, Turquie, LatAm), politique d'élimination.
Audit : qui a publié/lu, reproductibilité des scénarios.

Haute disponibilité et DR

Kafka: `replication. factor ≥ 3`, `min. insync. replicas ',' acks = all ', réplication croisée régionale (MM2) pour DR.
Flink/Streams : checkpoint + savepoint périodiques pour les versions contrôlées ; HA-JobManager.
OLAP : réplication de segments, lecture replicas ; failover tests (game day).

Performances et tuning

Les producteurs : batching ('linger. ms`, `batch. size '), compression (lz4/zstd).
Consumers : correct 'max. poll. interval ', pause des lots au backof.
Partitionnement : compte des lots du TPS cible et du parallélisme.
State: RocksDB options (block cache/write buffer), NVMe/IOPS, pinning.
Réseau : 10/25G, tuning TCP, dissuasion de n + 1 requêtes sink.

Mise en œuvre : technologies clés

Pneu : Apache Kafka (alternatives : Pulsar, Redpanda).
Traitement en continu : Apache Flink, Kafka Streams, ksqlDB, Spark Structured Streaming.
CDC : Debezium (MySQL/Postgres), connecteurs Outbox.
Dépôts de projections : ksqlDB tables, Kafka Streams store, Redis pour faible latence, ClickHouse/Druid/Pinot pour OLAP.
Feature store : Feast ou le sien - en ligne (Redis) + hors ligne (Parquet/BigQuery), garantie de cohérence.

Modèles de conception

Outbox → Kafka : chaque événement de domaine d'une transaction OBD.
Sagas : compensation par des événements ; l'orchestre est un stream.
Fan-out : un événement → anti-fraud, CRM, analytique, notations.
Materialized Views : leaders, équilibre, limites - sous la forme de tables mises à jour à partir d'un stream.
Reprocessing : reproduction des pics pour recalculer les agrégats/rétro-analytiques.

Exemples (concepts)

ksqlDB : leaders du tournoi (fenêtre glissante)

sql
CREATE STREAM bets_src (
bet_id VARCHAR KEY,
player_id VARCHAR,
amount DOUBLE,
ts BIGINT
) WITH (KAFKA_TOPIC='bets. placed. v1', VALUE_FORMAT='AVRO', TIMESTAMP='ts');

CREATE TABLE leaderboard AS
SELECT player_id,
SUM(amount) AS total_stake,
WINDOWSTART AS win_start,
WINDOWEND  AS win_end
FROM bets_src
WINDOW HOPPING (SIZE 10 MINUTES, ADVANCE BY 1 MINUTE)
GROUP BY player_id
EMIT CHANGES;

Flink (pseudo-code) : anti-frottement avec late-events

java stream
.assignTimestampsAndWatermarks(WatermarkStrategy. forBoundedOutOfOrderness(Duration. ofSeconds(10)))
.keyBy(e -> e. playerId)
.window(SlidingEventTimeWindows. of(Time. minutes(5), Time. minutes(1)))
.aggregate(scoreFunction, processWindow)
.sideOutputLateData(lateTag)
.addSink(riskTopic);

Tests de qualité des flux

Tests contractuels des schémas et de l'évolution (Schema Registry).
Charge : TPS cible, p99, comportement de dégradation sink.
Failure/chaos : chute des courtiers/nœuds, retards réseau, split-brain.
Deterministic replays : une nouvelle course de tops → les mêmes résultats.
Flux canaris : boucle de vérification du retard et de l'intégrité.

Check-list d'implémentation

1. Définir SLO (p99 E2E ≤ X c, lag ≤ Y, disponibilité ≥ Z).
2. Normaliser les schémas et les clés (player_id/bet_id).
3. Sélectionner l'architecture (Kappa pour les contours critiques).
4. Configurer outbox + CDC et isoler PII.
5. Définir les fenêtres, watermark, late-policy et DLQ/side outputs.
6. Activer l'EOS/idempotence sur les trajets monétaires.
7. Introduire la surveillance et les alertes sur lag, watermark, DLQ.
8. Fournir des HA/DR et des règlements de reprise.
9. Développer Feature Store et synchroniser en ligne/hors ligne.
10. Passer le game-day : travailler sur les pannes et la récupération.

Anti-modèles

Mélange event-time et processing-time sans stratégie consciente.
L'absence de schema governance → des versions « cassantes ».
Ignorer les données late et les « clés chaudes ».
Pas de stratégie de replay et de versioning des tops.
Tarifs/paiements sans idempotency et EOS.

Résultats

Le streaming temps réel n'est pas un « autre transport », mais une façon de penser : événements de domaine, SLO clairs, contrats de données, fenêtres et état, sécurité et observabilité. Pour iGaming, le Kafka + Flink/ksqlDB + Debezium + Materialized Views + Feature Store. Il donne des réponses millisecondes, la cohérence de l'analyse en ligne/hors ligne et la complexité contrôlée lorsque la charge augmente.