Event-Streaming and real-time data

(Section: Technology and Infrastructure)

Brief Summary

Event-Streaming is the processing and delivery of events at the time they appear. For iGaming, this means instant reaction to bets, deposits, anti-fraud signals, responsible game limits, tournament tables and personal offers. Base bricks: Event bus (Kafka/Pulsar), streaming engine (Flink/ksqlDB/Spark Structured Streaming), CDC from transactional databases (Debezium), Feature Store for online ML and real-time analytics (materialized views, OLAP)

Where is it critical in iGaming

Anti-fraud & risk: scoring transactions in <100-300 ms, correlation of behavioral patterns, blocking and escalation.
Responsible game: limit control, loss rate, abnormal behavior - alerts and real-time auto-restrictions.

Payments: status valves, webhooks PSP, smart-retry, balance projections, SLA "time-to-wallet."

Game events: calculation of tournament leaders (sliding windows), rounds of live games, real-time feeds for CRM/marketing.
Personalization: online features (RFM, propensity) → trigger campaigns, push/email within seconds.
Operational analytics: p95/p99 latency, funnel step conversion, platform health signals.

Architectural models

Lambda vs Kappa

Lambda: batch (DWH/ETL) + streaming (operative). Plus - flexibility and "cheap" bech; minus is double logic.
Kappa: everything is like a stream from a magazine (Kafka). Plus - a single code, event replay; minus - stricter infrastructure requirements.

Practice: for critical real-time contours - Kappa; for reporting/ML training - an additional batch circuit.

Event pipeline (reference)

1. Manufacturers: betting/payment services publish domain events (outbox → Kafka).
2. Bus: Kafka with parts by keys ('player _ id', 'bet _ id').
3. CDC: Debezium pulls changes from OLTP (balances, limits) to stream.
4. Streaming: Flink/ksqlDB/Spark - aggregations, windows, CEP, join's.
5. Projections: materialized tables (Kafka Streams state store/ksqlDB tables/Redis), OLAP (ClickHouse/Druid).
6. Consumers: anti-fraud, CRM, notifications, dashboards, trigger workflows.

Data Contracts and Schemas

Avro/Protobuf + Schema Registry: strict contracts, backward-compatible migrations.
Versioning: 'domain. event. v{n}`; prohibit breaking changes.
PII: tokenization/encryption, masking, purpose limitation (GDPR).

Delivery semantics and idempotency

At-least-once is a de facto standard (duplicates are possible) → idempotent-handling is required.
Exactly-once in streaming: Kafka + EOS transaction producers in Flink/Streams; more expensive, apply point (money/balance).
Outbox + CDC: a single source of truth from the service database, double write protection.
Dedup: key ('idempotency _ key'), deduplication table with TTL, upsert/merge.

Time windows and "late" data

• Tumbling - fixed slots (for example, a minute of revolution).
• Hopping - sliding in increments (for example, a window of 5 minutes in increments of 1 minute).
• Session - by inactivity (player sessions).
• Watermarks: event-time processing, lateness, DLQ/side-output evacuation.
• CEP (Complex Event Processing): patterns "A then B in 3 min," "N events in M seconds," "cancellation/compensation."

Status and scaling

Stateful operators: aggregations/joynes hold state (RocksDB state backend).
Changelog topics: reliability and state recovery.
Backpressure: auto-speed control, limits on system sink/外.
Key distribution: heavy hitters → key-salting, skew mitigation.

Monitoring and SLO

Stream SLO: p99 end-to-end latency (for example, ≤ 2 s), valid consumer lag, availability ≥ 99. 9%.
Metrics: throughput, lag by party, watermark delay, drop/late ratio, backpressure, busy time operators, GC/JVM.
Alerts: DLQ growth, watermark lag, EOS checkpoint failures, online/offline rassinh features.
Tracing: corelational IDs ('trace _ id', 'message _ id') through a producer-stream-consumer.

Safety and compliance

TLS/MTLS, ACL/RBAC on topics/tables, segmentation of sensitive domains (payments/CCM).
PII encryption in transit/on disk; secrets in Vault/SOPS.
Data retention & locality: storage by region (EU, Turkey, LatAm), removal policy.
Audit: who published/read, reproducibility of scripts.

High Availability and DR

Kafka: `replication. factor ≥ 3`, `min. insync. replicas', 'acks = all', cross-region replication (MM2) for DR.
Flink/Streams: periodic checkpoint + savepoint for controlled releases; HA-JobManager.
OLAP: segment replication, read replicas; failover (game day) tests.

Performance and tuning

Producers: butching ('linger. ms`, `batch. size '), compression (lz4/zstd).
Consumers: correct 'max. poll. interval ', pause of parties during backoff.
Partitioning: Counting parties from the target TPS and parallelism.
State: RocksDB options (block cache/write buffer), NVMe/IOPS, pinning.
Network: 10/25G, TCP tuning, n + 1 sink request containment.

Implementation: Key Technologies

Shina: Apache Kafka (alternatives: Pulsar, Redpanda).

Streaming: Apache Flink, Kafka Streams, ksqlDB, Spark Structured Streaming

CDC: Debezium (MySQL/Postgres), Outbox connectors.
Projection repositories: ksqlDB tables, Kafka Streams state store, Redis for low latency, ClickHouse/Druid/Pinot for OLAP.
Fichestor: Feast or own - online (Redis) + offline (Parquet/BigQuery), consistency guarantee.

Design patterns

Outbox → Kafka: each domain event from the DB transaction.
Sagas: Compensations Through Events; orchestration by stream.
Fan-out: one event → anti-fraud, CRM, analytics, notifications.
Materialized Views: leaderboards, balance, limits - in the form of tables that are updated from the stream.
Reprocessing: reproduction of topicals for recalculation of aggregates/retro analytics.

Examples (concepts)

ksqlDB: tournament leaders (sliding window)

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 with 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);

Thread quality testing

Contract tests of schemes and evolution (Schema Registry).
Loading: target TPS, p99, sink degradation behavior.
Failure/chaos: drop in brokers/nodes, network delays, split-brain.
Deterministic replays-Re-runs the topics → the same results.
Canary streams: loop for checking delay and integrity.

Implementation checklist

1. Define SLO (p99 E2E ≤ X c, lag ≤ Y, availability ≥ Z).
2. Standardize schemes and keys (player_id/bet_id).
3. Select Architecture (Kappa for critical loops).
4. Configure outbox + CDC and isolate PII.
5. Set windows, watermark, late-policy and DLQ/side outputs.
6. Enable EOS/idempotency on money paths.
7. Introduce monitoring and alerts for lag, watermark, DLQ.
8. Provide HA/DR and reprocessing procedures.
9. Deploy Feature Store and sync online/offline.
10. Spend game-day: working out failures and recovery.

Anti-patterns

Mixing event-time and processing-time without conscious policy.
Lack of schema governance → "breaking" releases.
Ignoring late data and hot keys.
Lack of replay strategy and versioning of topics.
Rates/payments without idempotency and EOS.

Summary

Real-time streaming is not "another transport," but a way of thinking: domain events, clear SLOs, data contracts, windows and status, security and observability. For iGaming, the sustainable set is Kafka + Flink/ksqlDB + Debezium + Materialized Views + Feature Store. It gives millisecond reactions, online/offline analytics consistency and controlled complexity as the load grows.