Dati Event-Streaming e real-time
(Sezione Tecnologia e infrastruttura)
Breve riepilogo
Event-Streaming è l'elaborazione e la consegna degli eventi al momento della loro comparsa. Questo significa una reazione immediata alle scommesse, ai depositi, ai segnali antifrode, ai limiti del gioco responsabile, ai tornei e agli offerenti personali. Mattoni di base: bus di eventi (Kafka/Pulsar), motore di elaborazione in streaming (Flink/ksqlDB/Spark Struttured Streaming), CDC da database transazionali (Debezium), Feature Store per ML online e real-time (visualizzazioni materializzate, OLAP).
Dove è critico nel iGaming
Antifrod & Risk: mapping delle transazioni in <100-300 ms, correlazione tra pattern comportamentali, blocco e escalation.
Gioco responsabile: controllo dei limiti, velocità di perdita, comportamento anomalo - alert e limitazioni in tempo reale.
Pagamenti: ventili statutari, webhooks PSP, smart-retry, proiezioni di bilanci, SLA «time-to-wallet».
I videogiochi includono il calcolo dei leader dei tornei (sliding finestre), i giri dei giochi live, i nastri real-time per CRM/marketing.
Personalizzazione: file online (RFM, propensity), campagne di trigger, push/email in secondi.
Analisi online: p95/p99 latency, conversione dei passaggi del vortice, segnali health della piattaforma.
Modelli architettonici
Lambda vs Kappa
Lambda: batch (DWH/ETL) + streaming (operative). In più, flessibilità e «low cost»; meno è una doppia logica.
Kappa: tutto come flusso dal registro (Kafka). In più, un unico codice, reigra gli eventi; meno - requisiti di infrastruttura più severi.
Pratica: per i tracciati real-time critici - Kappa; per report/apprendimento ML è un tracciato batch aggiuntivo.
Catena di montaggio eventi (arbitro)
1. Produttori: i servizi scommesse/pagamenti pubblicano eventi di dominio (outbox → Kafka).
2. Pneumatico: Kafka con le parti chiave ('player _ id', 'bet _ id').
3. CDC: Debezium estrae le modifiche da OLTP (bilanci, limiti) a strame.
4. Flusso: aggregazioni, finestre, CEP, join's.
5. Le proiezioni sono tabelle materializzate (Kafka Streams State Store/ ksqlDB/Redis), OLAP (ClickHouse/Druid).
6. Consumatori: antifrode, CRM, notifiche, dashboard, workflow a trigger.
Contratti dati e schemi
Avro/Protobuf + Schema Registry: contratti rigorosi, migrazioni backward-compatibili.
Versioning: 'domain. event. v{n}`; Vietare le modifiche distruttive.
PII: tornizzazione/crittografia, occultamento, purpose limitation (GDPR).
Semantiche di spedizione e idempotici
At-least-once è uno standard di fatto (possibili duplicati) obbligatorio idempotent-handling.
Exactly-once in streaming: produttori transazionali Kafka + EOS in Flink/Streams; più costoso, applicare in modo puntuale (denaro/saldo).
Outbox + CDC: un'unica fonte di verità dal database del servizio, protezione contro la doppia scrittura.
Dedup: chiave ('idempotency _ key'), tabella di deduplicazione con TTL, upsert/merge.
Finestre temporanee e dati «tardivi»
Finestre:- Tumbling - slot fissi (ad esempio un minuto di rotazione).
- Hopping - Scorri a passo (ad esempio, una finestra di 5 minuti con un passo di 1 minuto).
- Sessione - per inattività (sessione del giocatore).
- Watermarks: elaborazione event-time, tolleranza lateness, evacuazione DLQ/side-output.
- CEP (Complex Event Processing) - Pattern A seguito B in 3 minuti, N eventi in M secondi, Annulla/Compensazione.
Stato e ridimensionamento
Operatori Stateful: aggregazioni/gioielli mantengono lo stato (RocksDB state backend).
Changelog topics: affidabilità e ripristino state.
Backpressure: regolazione automatica della velocità, limiti di sink/外 del sistema.
La distribuzione delle chiavi: chiavi hot (heavy hitters), key-salting, skew mitigation.
Monitoraggio e SLO
Flusso SLO: p99 end-to-end latency (ad esempio, ≤ 2 c), consumer lag valido, disponibilità ≥ 99. 9%.
Metriche: throughput, lag per partenze, watermark delay, drop/late ratio, backpressure, busy time degli operatori, GC/JVM.
La crescita del DLQ, il ritardo del watermark, i fallimenti degli checkpoint EOS, le insidie online/offline.
Tracing: ID corellario («trace _ id», «messaggistica _ id») attraverso il producer-strim-concerter.
Protezione e compliance
TLS/MTLS, ACL/RBAC su top/tabelle, segmentazione di domini sensibili (pagamenti/CUS).
Crittografia PII in transito/su disco; segreti in Vault/SOPS.
Data retention & locality - Storage per regione (UE, Turchia, LatAm), polizza di eliminazione.
Controllo: chi ha pubblicato/letto, riproducibilità degli script.
Elevata disponibilità e DR
Kafka: `replication. factor ≥ 3`, `min. insync. replica ',' acks = all ', replica crociata regionale (MM2) per DR.
Flink/Streams: checkpoint + savepoint periodici per i rilasci controllati; HA-JobManager.
OLAP Replica segmenti, read replica test failover (game day).
Prestazioni e tuning
Venditori: batching ('linger. ms`, `batch. size '), compressione (lz4/zstd).
Le consolle sono corrette "max. poll. interval, pausa delle partizioni al bacof.
Partizionamento: conteggio delle partizioni da target TPS e parallelismo.
State: RocksDB options (block cache/write buffer), NVMe/IOPS, pinning.
Network: 10/25G, sintonizzatore TCP, contenimento n + 1 richieste sink.
Implementazione: tecnologie chiave
Pneumatico: Apache Kafka (alternative Pulsar, Redpanda).
Streaming: Apache Flink, Kafka Streams, ksqlDB, Spark Struttured Streaming.
CDC: Debezium (MySQL/Postgres), connettori Outbox.
I depositi di proiezioni sono ksqlDB, Kafka Streams State Store, Redis per bassa latenza, ClickHouse/Druid/Pinot per OLAP.
Feast o Feast - online (Redis) + offline (Parquet/BigQuery), garanzia di consistenza.
Modelli di progettazione
Outbox → Kafka: ogni evento di dominio di una transazione database.
Pagamenti attraverso eventi; l'orchestra è uno striam.
Fan-out: un evento, antifrode, CRM, analisi, notifica.
Materialization Views: liderbord, bilanci, limiti - come tabelle che si aggiornano dallo striam.
Riprocessing: riproduzione di topic per ricalcolare aggregazioni/analisi retro.
Esempi (concetti)
ksqlDB Leader torneo (finestra scorrevole)
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 (pseudocode) - Controllo antifrode con 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);Test di qualità dei flussi
Test contract degli schemi e dell'evoluzione (Schema Registry).
Carico: target TPS, p99, comportamento in caso di degrado sink.
Failure/chaos: calo broker/nodi, ritardi di rete, split-brain.
Deterministic replays - Riprova i topici con gli stessi risultati.
Flusso canary - Tracciato di verifica di latenza e integrità.
Assegno foglio di implementazione
1. Imposta SLO (p99 E2E ≤ X c, lag ≤ Y, disponibilità ≥ Z).
2. Standard schemi e chiavi (player _ id/bet _ id).
3. Selezionare un'architettura (Kappa per i tracciati critici).
4. Configura outbox + CDC e isola PII.
5. Imposta finestre, watermark, late-policy e DLQ/side outputs.
6. Abilita EOS/idampotenza sui binari.
7. Inserire il monitoraggio e gli alert su lag, watermark, DLQ.
8. Fornire le regole HE/DR e reprocessing.
9. Espandi Feature Store e sincronizza online/offline.
10. Esegui game-day - Disattivazione e ripristino.
Antipattern
Miscelare event-time e processing-time senza un criterio consapevole.
L'assenza di una schema governance è una release «rottura».
Ignora late data e chiavi hot.
Nessuna strategia replay e versioning topic.
Scommesse/pagamenti senza idempotency o EOS.
Riepilogo
Lo streaming real-time non è un'altro trasporto ", ma un modo di pensare: eventi di dominio, SLO chiari, contratti di dati, finestre e condizioni, sicurezza e osservabilità. Kafka + + Debezium + Materialization Views + Feature Store per un set più sostenibile. Offre reazioni millisecondi, analisi online/offline coerenti e complessità controllate quando il carico aumenta.