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 antifrod, 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

Antifrod & 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 : фичи en ligne (RFM, propensity) → триггерные 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 : antifrod, 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 fiches 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.
Fichestor : 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 strim.
Fan-out : un événement → antifrod, CRM, analytique, notations.
Materialized Views : leaders, équilibre, limites - sous la forme de tables mises à jour à partir d'un strim.
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é.

Chèque 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.