Event-Streaming und Echtzeitdaten

(Abschnitt: Technologie und Infrastruktur)

Kurze Zusammenfassung

Event-Streaming ist die Verarbeitung und Bereitstellung von Ereignissen zum Zeitpunkt ihres Auftretens. Für iGaming bedeutet dies eine sofortige Reaktion auf Wetten, Einzahlungen, Anti-Fraud-Signale, verantwortungsvolle Spiellimits, Turniertabellen und persönliche Angebote. Basisbausteine: Ereignisbus (Kafka/Pulsar), Stream Processing Engine (Flink/ksqlDB/Spark Structured Streaming), CDC aus transaktionalen DBs (Debezium), Feature Store für Online ML und Real-Time Analytics (materialisierte Ansichten, OLAPs)

Wo es bei iGaming kritisch ist

Fraud & Risk: Scoring von Transaktionen in <100-300 ms, Korrelation von Verhaltensmustern, Blockaden und Eskalationen.
Verantwortungsvolles Spielen: Limitkontrolle, Verlustrate, abnormales Verhalten - Alerts und Auto-Limits in Echtzeit.
Zahlungen: Statusventile, Webhooks PSP, Smart-Retry, Projektionen von Bilanzen, SLA „Time-to-Wallet“.
Spielevents: Berechnung von Turnierleitern (Sliding-Fenster), Live-Spielrunden, Echtzeit-Feeds für CRM/Marketing.
Personalisierung: Online-Funktionen (RFM, Propensity) → Trigger-Kampagnen, Push/E-Mail innerhalb von Sekunden.
Operative Analyse: p95/p99 Latenz, Umwandlung von Trichterschritten, Gesundheitssignale der Plattform.

Architekturmodelle

Lambda vs Kappa

Lambda: Batch (DWH/ETL) + Streaming (operativ). Plus - Flexibilität und „billiger“ Beutel; Minus - doppelte Logik.
Kappa: alles ist wie ein Stream aus einem Magazin (Kafka). Plus - einheitlicher Code, Wiederspiel von Ereignissen; minus - strengere Anforderungen an die Infrastruktur.

Praxis: für echtzeitkritische Konturen - Kappa; für Reporting/ML-Training - inkrementelle Batch-Schaltung.

Ereignispipeline (Referenz)

1. Hersteller: Wett-/Zahlungsdienste veröffentlichen Domain-Events (Outbox → Kafka).
2. Bus: Kafka mit Schlüsselpartitionen ('player _ id', 'bet _ id').
3. CDC: Debezium zieht Änderungen von OLTPs (Salden, Limits) in den Stream.
4. Streaming Verarbeitung: Flink/ksqlDB/Spark - Aggregationen, Fenster, CEP, join 's.
5. Projektionen: materialisierte Tabellen (Kafka Streams state store/ksqlDB tables/Redis), OLAP (ClickHouse/Druid).
6. Verbraucher: Fraud, CRM, Benachrichtigungen, Dashboards, Trigger-Workshops.

Datenverträge und Schemata

Avro/Protobuf + Schema Registry: strenge Verträge, backward-kompatible Migrationen.
Versionierung: 'Domäne. event. v{n}`; Störende Veränderungen verbieten.
PII: Tokenisierung/Verschlüsselung, Maskierung, Purpose Limitation (DSGVO).

Liefersemantik und Idempotenz

At-least-once ist de facto der Standard (Duplikate sind möglich) → idempotent-handling ist Pflicht.
Exactly-once im Streaming: Kafka + EOS Transaction Producer in Flink/Streams; teurer, punktweise anwenden (Geld/Guthaben).
Outbox + CDC: eine einzige Quelle der Wahrheit aus dem DB-Service, Schutz vor doppelter Aufzeichnung.
Dedup: Schlüssel ('idempotency _ key'), Deduplizierungstabelle mit TTL, upsert/merge.

Zeitfenster und „späte“ Daten

• Tumbling sind feste Slots (z.B. Umdrehungsminute).
• Hopping - gleitend in Schritten (z.B. 5 min Fenster in Schritten von 1 min).
• Session - durch Inaktivität (Spielersitzungen).
• Watermarks: Event-Time-Verarbeitung, Zulassung von „late-time“ (lateness), Evakuierung in DLQ/side-output.
• CEP (Complex Event Processing): Muster „A dann B in 3 min“, „N Ereignisse in M Sekunden“, „Cancel/Compensation“.

Status und Skalierung

Stateful Operatoren: Aggregationen/Joins halten den Status (RocksDB state backend).
Changelog-Themen: Zuverlässigkeit und Wiederherstellung des Staates.
Backpressure: automatische Geschwindigkeitsregelung, Grenzwerte für sink/外 Systeme.
Schlüsselverteilung: Hot Keys (Heavy Hitters) → Key-Salting, Skew Mitigation.

Überwachung und SLO

Stream-SLO: p99 Ende-zu-Ende-Latenz (z. B. ≤ 2 s), zulässige Verbraucherverzögerung, Verfügbarkeit ≥ 99. 9%.
Metriken: throughput, lag nach Partitur, watermark delay, drop/late ratio, backpressure, busy time operators, GC/JVM.
Alertas: DLQ-Wachstum, Wasserzeichen-Rückstand, EOS-Checkpoint-Flops, Rassinh-Fiches online/offline.
Tracing: Korrelative IDs ('trace _ id', 'message _ id') durch den Producer-Stream-Consumer.

Sicherheit und Compliance

TLS/MTLS, ACL/RBAC in Topics/Tabellen, Segmentierung sensibler Domains (Payments/CUS).
PII-Verschlüsselung im Transit/auf Festplatte; Geheimnisse in Vault/SOPS.
Datenretention & Lokalität: Speicherung nach Region (EU, Türkei, LatAm), Löschpolitik.
Audit: wer veröffentlicht/gelesen hat, Reproduzierbarkeit der Szenarien.

Hohe Verfügbarkeit und DR

Kafka: `replication. factor ≥ 3`, `min. insync. replicas', 'acks = all', regionalübergreifende Replikation (MM2) für DR.
Flink/Streams: periodischer Checkpoint + Savepoint für kontrollierte Releases; HA-JobManager.
OLAP: Segmentreplikation, read replicas; Failover-Tests (Spieltag).

Leistung und Tuning

Produzenten: batching ('linger. ms`, `batch. size'), Kompression (lz4/zstd).
Consumers: die richtige' max. poll. interval', Pause der Parties beim Backoff.
Partitionierung: Partituren zählen aus dem Ziel TPS und Parallelität.
State: RocksDB options (block cache/write buffer), NVMe/IOPS, pinning.
Netzwerk: 10/25G, TCP-Tuning, Abschreckung von n + 1-sink-Anfragen.

Umsetzung: Schlüsseltechnologien

Reifen: Apache Kafka (Alternativen: Pulsar, Redpanda).
Streaming Verarbeitung: Apache Flink, Kafka Streams, ksqlDB, Spark Structured Streaming.
CDC: Debezium (MySQL/Postgres), Outbox-Konnektoren.
Projektionsspeicher: ksqlDB Tabellen, Kafka Streams state store, Redis für niedrige Latenz, ClickHouse/Druid/Pinot für OLAP.
Fichestor: Fest oder eigene - online (Redis) + offline (Parkett/BigQuery), Garantie für die Konsistenz.

Entwurfsmuster

Outbox → Kafka: Jedes Domänenereignis aus einer DB-Transaktion.
Sagas: Entschädigung durch Ereignisse; Orchestrierung - Stream.
Fan-out: ein Ereignis → Betrug, CRM, Analytik, Benachrichtigung.
Materialisierte Ansichten: Leaderboards, Balance, Limits - in Form von Tabellen, die aus dem Stream aktualisiert werden.
Reprocessing: Reproduktion von Topics für die Neuberechnung von Aggregaten/Retro-Analysen.

Beispiele (Konzepte)

ksqlDB: Turnierführer (Schiebefenster)

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): Anti-Fraud-Scoring c 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);

Testen der Qualität von Threads

Vertragstests von Schemata und Evolution (Schema Registry).
Last: Ziel TPS, p99, sink Degradationsverhalten.
Ausfall/Chaos: Broker/Knoten fallen, Netzwerk-Latenzen, Split-Brain.
Deterministische Replays: Wiederholter Durchlauf von Topics → die gleichen Ergebnisse.
Canary-Streams: Schleife zur Überprüfung von Verzögerung und Integrität.

Checkliste für die Implementierung

1. Bestimmen Sie SLO (p99 E2E ≤ X c, lag ≤ Y, Verfügbarkeit ≥ Z).
2. Standardisieren Sie Schemata und Schlüssel (player_id/bet_id).
3. Architektur auswählen (Kappa für kritische Konturen).
4. Konfigurieren Sie outbox + CDC und isolieren Sie PII.
5. Legen Sie Fenster, Wasserzeichen, late-policy und DLQ/side outputs fest.
6. EOS/Idempotenz auf Geldwegen aktivieren.
7. Führen Sie Überwachung und Warnungen auf Lag, Wasserzeichen, DLQ ein.
8. HA/DR und Reprocessing-Vorschriften sicherstellen.
9. Feature Store und Online-/Offline-Synchronisierung bereitstellen.
10. Halten Sie ein Spiel-Tag: Arbeit Ausfälle und Wiederherstellung.

Antimuster

Vermischung von Event-Time und Processing-Time ohne bewusste Politik.
Fehlende Schema-Governance → „Breaking“ -Veröffentlichungen.
Ignorieren Sie Late Data und Hot Keys.
Fehlende Replay-Strategie und Topic-Versionierung.
Preise/Zahlungen ohne idempotency und EOS.

Ergebnisse

Real-Time-Streaming ist kein „anderer Transport“, sondern eine Denkweise: Domain-Events, klare SLOs, Datenverträge, Fenster und Zustand, Sicherheit und Beobachtbarkeit. Für iGaming ist das nachhaltige Set Kafka + Flink/ksqlDB + Debezium + Materialized Views + Feature Store. Es liefert Millisekunden-Reaktionen, Online/Offline-Analytics-Konsistenz und kontrollierte Komplexität bei steigender Belastung.