Event-Streaming і real-time дані
(Розділ: Технології та Інфраструктура)
Коротке резюме
Event-Streaming - це обробка і доставка подій в момент їх появи. Для iGaming це означає миттєву реакцію на ставки, депозити, антифрод-сигнали, ліміти відповідальної гри, турнірні таблиці та персональні оффери. Базові цеглини: шина подій (Kafka/Pulsar), рушій потокової обробки (Flink/ksqlDB/Spark Structured Streaming), CDC з транзакційних БД (Debezium), Feature Store для онлайн-ML і real-time аналітика (матеріалізовані уявлення, OLAP).
Де це критично в iGaming
Антифрод & ризик: скоринг транзакцій в <100-300 мс, кореляція поведінкових патернів, блокування та ескалації.
Відповідальна гра: контроль лімітів, швидкість втрат, аномальна поведінка - алерти і авто-обмеження в реальному часі.
Платежі: статусні вентили, webhooks PSP, smart-retry, проекції балансів, SLA «time-to-wallet».
Ігрові івенти: розрахунок лідерів турнірів (sliding вікна), раунди live-ігор, real-time стрічки для CRM/маркетингу.
Персоналізація: онлайн-фічі (RFM, propensity) → тригерні кампанії, push/email протягом секунд.
Оперативна аналітика: p95/p99 latency, конверсія кроків воронки, health-сигнали платформи.
Архітектурні моделі
Lambda vs Kappa
Lambda: batch (DWH/ETL) + streaming (оператив). Плюс - гнучкість і «дешевий» беч; мінус - подвійна логіка.
Kappa: всі - як потік з журналу (Kafka). Плюс - єдиний код, реігра подій; мінус - суворіше вимоги до інфраструктури.
Практика: для критичних real-time контурів - Kappa; для звітності/ML-навчання - додатковий batch-контур.
Конвеєр подій (референс)
1. Виробники: сервіси ставок/платежів публікують доменні події (outbox → Kafka).
2. Шина: Kafka з партіями за ключами ('player _ id','bet _ id').
3. CDC: Debezium витягує зміни з OLTP (баланси, ліміти) в стрім.
4. Потокова обробка: Flink/ksqlDB/Spark - агрегації, вікна, CEP, join'и.
5. Проекції: матеріалізовані таблиці (Kafka Streams state store/ksqlDB tables/Redis), OLAP (ClickHouse/Druid).
6. Споживачі: антифрод, CRM, повідомлення, дашборди, тригерні воркфлоу.
Контракти даних і схеми
Avro/Protobuf + Schema Registry: суворі контракти, backward-compatible міграції.
Версіонування: `domain. event. v{n}`; забороняти ламаючі зміни.
PII: токенізація/шифрування, маскування, purpose limitation (GDPR).
Семантики доставки та ідемпотентність
At-least-once - де-факто стандарт (можливі дублікати) → обов'язковий idempotent-handling.
Exactly-once в стрімінгу: транзакційні продьюсери Kafka + EOS в Flink/Streams; дорожче, застосовуйте точково (гроші/баланс).
Outbox + CDC: єдине джерело правди з БД сервісу, захист від подвійного запису.
Dedup: ключ ('idempotency _ key'), таблиця дедуплікації з TTL, upsert/merge.
Тимчасові вікна та «пізні» дані
Вікна:- Tumbling - фіксовані слоти (наприклад, хвилина обороту).
- Hopping - ковзаючі з кроком (наприклад, вікно 5 хв з кроком 1 хв).
- Session - по неактивності (сесії гравця).
- Watermarks: обробка по event-time, допуск «пізняків» (lateness), евакуація в DLQ/side-output.
- CEP (Complex Event Processing): патерни «A потім B в 3 хв», «N подій за M секунд», «скасування/компенсація».
Стан і масштабування
Stateful оператори: агрегації/джойни тримають стан (RocksDB state backend).
Changelog topics: надійність і відновлення state.
Backpressure: авто-регулювання швидкості, ліміти на sink/外 системи.
Розподіл ключів: гарячі ключі (heavy hitters) → key-salting, skew mitigation.
Моніторинг та SLO
SLO потоку: p99 end-to-end latency (наприклад, ≤ 2 с), допустимий consumer lag, доступність ≥ 99. 9%.
Метрики: throughput, lag по партіях, watermark delay, drop/late ratio, backpressure, busy time операторів, GC/JVM.
Алерти: зростання DLQ, відставання watermark, провали EOS чекпоінтів, розсинх фічів онлайн/офлайн.
Трейсинг: кореляційні ID ('trace _ id','message _ id') крізь продьюсер-стрім-консьюмер.
Безпека та комплаєнс
TLS/MTLS, ACL/RBAC на топіки/таблиці, сегментація чутливих доменів (платежі/КУС).
Шифрування PII в транзиті/на диску; секрети в Vault/SOPS.
Data retention & locality: зберігання по регіонах (ЄС, Туреччина, ЛатАм), поліс видалення.
Аудит: хто публікував/читав, відтворюваність сценаріїв.
Висока доступність і DR
Kafka: `replication. factor ≥ 3`, `min. insync. replicas','acks = all', крос-регіональна реплікація (MM2) для DR.
Flink/Streams: періодичні checkpoint + savepoint для контрольованих релізів; HA-JobManager.
OLAP: реплікація сегментів, read replicas; тести failover (game day).
Продуктивність і тюнінг
Продьюсери: батчинг ('linger. ms`, `batch. size'), компресія (lz4/zstd).
Консьюмери: правильний'max. poll. interval', пауза партій при бекофі.
Партіонування: рахунок партій з цільового TPS і паралелізму.
State: RocksDB options (block cache/write buffer), NVMe/IOPS, pinning.
Network: 10/25G, TCP-тюнінг, стримування n + 1 sink-запитів.
Реалізація: ключові технології
Шина: Apache Kafka (альтернативи: Pulsar, Redpanda).
Потокова обробка: Apache Flink, Kafka Streams, ksqlDB, Spark Structured Streaming.
CDC: Debezium (MySQL/Postgres), Outbox-конектори.
Сховища проекцій: ksqlDB tables, Kafka Streams state store, Redis для низької латентності, ClickHouse/Druid/Pinot для OLAP.
Фічестор: Feast або власний - онлайн (Redis) + офлайн (Parquet/BigQuery), гарантія консистентності.
Патерни проектування
Outbox → Kafka: кожна доменна подія з транзакції БД.
Саги: компенсації через події; оркестрація - стрімом.
Fan-out: одна подія → антифрод, CRM, аналітика, нотифікації.
Materialized Views: лідерборди, баланс, ліміти - у вигляді таблиць, що оновлюються зі стріму.
Reprocessing: відтворення топіків для перерахунку агрегатів/ретро-аналітики.
Приклади (концепти)
ksqlDB: лідери турніру (ковзне вікно)
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 (псевдокод): антифрод-скоринг 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);Тестування якості потоків
Contract-тести схем та еволюції (Schema Registry).
Навантажувальні: цільової TPS, p99, поведінка при деградації sink.
Failure/chaos: падіння брокерів/вузлів, мережеві затримки, split-brain.
Deterministic replays: повторний прогін топіків → однакові результати.
Canary-потоки: контур перевірки затримки і цілісності.
Чек-лист впровадження
1. Визначити SLO (p99 E2E ≤ X c, lag ≤ Y, доступність ≥ Z).
2. Стандартизувати схеми і ключі (player_id/bet_id).
3. Вибрати архітектуру (Kappa для критичних контурів).
4. Налаштувати outbox + CDC та ізолювати PII.
5. Задати вікна, watermark, late-policy і DLQ/side outputs.
6. Включити EOS/ідемпотентність на грошових шляхах.
7. Ввести моніторинг і алерти на lag, watermark, DLQ.
8. Забезпечити HA/DR і регламенти reprocessing.
9. Розгорнути Feature Store і синхронізацію онлайн/офлайн.
10. Провести game-day: відпрацювання відмов і відновлення.
Антипатерни
Змішування event-time і processing-time без усвідомленої політики.
Відсутність schema governance → «ламаючі» релізи.
Ігнорування late data і «гарячих ключів».
Відсутність replay-стратегії і версіонування топіків.
Ставки/платежі без idempotency і EOS.
Підсумки
Real-time стрімінг - це не «ще один транспорт», а спосіб мислення: доменні події, чіткі SLO, контракти даних, вікна і стан, безпека і спостережуваність. Для iGaming стійкий набір - Kafka + Flink/ksqlDB + Debezium + Materialized Views + Feature Store. Він дає мілісекундні реакції, узгодженість онлайн/офлайн аналітики і контрольовану складність при зростанні навантаження.