Event-Streaming va real-time ma’lumotlari

(Bo’lim: Texnologiyalar va infratuzilma)

Qisqacha xulosa

Event-Streaming - voqealar paydo bo’lganda ularni qayta ishlash va yetkazib berish. iGaming uchun bu stavkalar, depozitlar, antifrod signallari, mas’uliyatli o’yin limitlari, turnir jadvallari va shaxsiy offeralarga tezkor munosabatni anglatadi. Bazaviy g’ishtlar: voqealar shinasi (Kafka/Pulsar), oqimga ishlov berish dvigateli (Flink/ksqlDB/Spark Structured Streaming), tranzaksion DBdan CDC (Debezium), onlayn-ML uchun Feature Store va real-time analitika (materiallashtirilgan tushunchalar, OLAP).

Bu iGaming’da muhim

Antifrod va xavf: <100-300 ms skoring tranzaksiyalari, xulq-atvor patternlari korrelyatsiyasi, blokirovka va eskalatsiya.
Mas’uliyatli o’yin: limitlarni nazorat qilish, yo’qotish tezligi, g’ayritabiiy xatti-harakatlar - real vaqtdagi alertlar va avto-cheklovlar.
To’lovlar: maqom ventillari, webhooks PSP, smart-retry, balans proyeksiyalari, SLA «time-to-wallet».
O’yin tadbirlari: turnir peshqadamlari (sliding oyna), live-o’yinlar raundlari, CRM/marketing uchun real-time lentalar hisobi.
Personalizatsiya: onlayn fichlar (RFM, propensity) → trigger kampaniyalari, push/email soniya davomida.
Tezkor tahlil: p95/p99 latency, huni qadamlarini konvertatsiya qilish, platformaning health-signallari.

Arxitektura modellari

Lambda vs Kappa

Lambda: batch (DWH/ETL) + streaming (operiv). Plyus - moslashuvchanlik va «arzon» bach; minus - ikki tomonlama mantiq.
Kappa: hamma narsa jurnaldan oqimga o’xshaydi (Kafka). Plyus - yagona kod, voqealar reigrasi; minus - infratuzilmaga nisbatan qattiqroq talablar.

Amaliyot: tanqidiy real-time konturlari uchun - Kappa; hisobot/ML-o’qitish uchun - qo’shimcha batch-kontur.

Voqealar konveyeri (referens)

1. Ishlab chiqaruvchilar: stavkalar/to’lovlar xizmatlari domen voqealarini e’lon qiladi (outbox → Kafka).
2. Shina: Kafka (’player _ id’,’bet _ id’).
3. CDC: Debezium OLTP (balanslar, limitlar) dagi oʻzgarishlarni oqimga tortadi.
4. Flink/ksqlDB/Spark - agregatsiyalar, derazalar, CEP, join’lar.
5. Proyeksiyalar: materiallashtirilgan jadvallar (Kafka Streams state store/ksqlDB tables/Redis), OLAP (ClickHouse/Druid).
6. Iste’molchilar: antifrod, CRM, bildirishnomalar, dashbordlar, trigger mashg’ulotlari.

Ma’lumotlar kontraktlari va sxemalar

Yevro/Protobuf + Schema Registry: qat’iy kontraktlar, backward-compatible migratsiya.
Version:’domain. event. v{n}`; buzuvchi o’zgartirishlarni taqiqlash.
PII: tokenlash/shifrlash, niqoblash, purpose limitation (GDPR).

Yetkazib berish semantikasi va idempotentlik

At-least-once - de-fakto standart (dublikatlar bo’lishi mumkin) → majburiy idempotent-handling.
Exactly-once strimingda: Kafka + EOS tranzaksion prodyuserlari Flink/Streams; qimmatroq, maqsadli foydalaning (pul/balans).
Outbox + CDC: Service DBdan yagona haqiqat manbai, ikki marta yozishdan himoya qilish.
Dedup: kalit (’idempotency _ key’), TTL bilan deduplikatsiya jadvali, upsert/merge.

Vaqtinchalik oynalar va «kech» maʼlumotlar

• Tumbling - belgilangan slotlar (masalan, aylanish daqiqasi).
• Hopping - qadam bilan sirg’aluvchi (masalan, 1 daqiqa qadam bilan 5 daqiqa).
• Session - harakatsizligi bo’yicha (o’yinchining sessiyasi).
• Watermarks: event-time bo’yicha ishlov berish, kechikish (lateness), DLQ/side-output ga evakuatsiya qilish.
• CEP (Complex Event Processing): «A keyin 3 daqiqada B», «M soniyada N hodisa», «bekor qilish/kompensatsiya» patternlari.

Holati va masshtablari

Stateful operatorlari: agregatsiyalar/joylar holatini saqlaydi (RocksDB state backend).
Changelog topics: ishonchlilik va tiklash state.
Backpressure: tezlikni avto-sozlash, tizimning sink/ limitlari.
Kalitlarni taqsimlash: issiq kalitlar (heavy hitters) → key-salting, skew mitigation.

Monitoring va SLO

SLO oqimi: p99 end-to-end latency (masalan, ≤ 2 s), ruxsat etilgan consumer lag, foydalanish imkoniyati ≥ 99. 9%.
Metriklar: throughput, partiyalar bo’yicha lag, watermark delay, drop/late ratio, backpressure, busy time operatorlari, GC/JVM.
Alertlar: DLQning o’sishi, watermark orqada qolishi, EOS chek pointlarining muvaffaqiyatsizliklari, onlayn/oflayn fichlarning tarqalishi.
Treysing: prodyuser-strim-konsumer orqali korelatsiya ID (’trace _ id’,’message _ id’).

Xavfsizlik va komplayens

TLS/MTLS, ACL/RBAC uchun topiklar/jadvallar, sezgir domenlar segmentatsiyasi (to’lovlar/KTS).
Tranzit/diskda PII shifrlash; Vault/SOPS sirlari.
Data retention & locality: hududlar bo’yicha saqlash (EI, Turkiya, LatAm), olib tashlash siyosati.
Audit: kim chop etgan/o’qigan, ssenariylarning takrorlanuvchanligi.

Yuqori foydalanish imkoniyati va DR

Kafka: `replication. factor ≥ 3`, `min. insync. replicas’,’acks = all’, DR uchun kross-mintaqaviy replikatsiya (MM2).
Flink/Streams: nazorat qilinadigan relizlar uchun davriy checkpoint + savepoint; HA-JobManager.
OLAP: segmentlarning replikatsiyasi, read replicas; testlar failover (game day).

Unumdorlik va tyuning

Prodyuserlar: batching (’linger. ms`, `batch. size’), siqish (lz4/zstd).
Konsumerlar: toʻgʻri’max. poll. interval’, bekofda partiyalar pauzasi.
Partiyalashtirish: maqsadli TPS va parallelizmdan iborat partiyalar hisobi.
State: RocksDB options (block cache/write buffer), NVMe/IOPS, pinning.
Network: 10/25G, TCP-tyuning, n + 1 sink-soʻrovlarni ushlab turish.

Amalga oshirish: asosiy texnologiyalar

Shina: Apache Kafka (muqobil: Pulsar, Redpanda).
Qayta ishlash: Apache Flink, Kafka Streams, ksqlDB, Spark Structured Streaming.
CDC: Debezium (MySQL/Postgres), Outbox-konnektorlar.
Proyeksiya omborlari: ksqlDB tables, Kafka Streams state store, Redis past latentlik uchun, ClickHouse/Druid/Pinot OLAP uchun.
Fichestor: Feast yoki xususiy - onlayn (Redis) + oflayn (Parquet/BigQuery), konsistentlik kafolati.

Loyihalash patternlari

Outbox → Kafka: DB tranzaksiyasidagi har bir domen voqeasi.
Sagʻanalar: hodisalar orqali kompensatsiyalar; orkestr - oqim.
Fan-out: bitta hodisa → antifrod, CRM, tahlillar, notifikatsiyalar.
Materialized Views: liderbordlar, balanslar, limitlar - oqimdan yangilanadigan jadvallar ko’rinishida.
Reprocessing: agregatlarni/retro tahlillarni qayta hisoblash uchun topiklarni takrorlash.

Namunalar (konsepsiyalar)

ksqlDB: turnir peshqadamlari

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 (psevdokod): antifrod-skoring 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);

Oqim sifatini sinash

Sxemalar va evolyutsiya contract-testlari (Schema Registry).
Yuklash: maqsadli TPS, p99, sink degradatsiyasidagi xatti-harakatlar.
Failure/chaos: brokerlar/tugunlarning tushishi, tarmoqdagi kechikishlar, split-brain.
Deterministic replays: topiklarni takrorlash → bir xil natijalar.
Canary oqimlari: kechikish va yaxlitlikni tekshirish konturi.

Joriy etish chek-varaqasi

1. SLO (p99 E2E ≤ X c, lag ≤ Y, foydalanish imkoniyati ≥ Z) belgilansin.
2. Sxemalar va kalitlarni standartlashtirish (player_id/bet_id).
3. Arxitekturani tanlash (kritik konturlar uchun Kappa).
4. Outbox + CDC ni moslash va PIIni izolyatsiya qilish.
5. Oynalar, watermark, late-policy va DLQ/side outputs.
6. Pul yo’llarida EOS/idempotentlikni yoqish.
7. lag, watermark, DLQ ga monitoring va alertlar kiritish.
8. HA/DR va reprocessing reglamentlarini ta’minlash.
9. Feature Store va sinxronizatsiyani onlayn/oflayn tarzda joylashtirish.
10. Game-day oʻtkazish: nosozliklar va tiklash.

Antipatternlar

Ongli siyosatsiz event-time va processing-time aralashtirish.
Schema governance → «buzuvchi» relizlarning yo’qligi.
Late data va «issiq kalitlar» ni eʼtiborsiz qoldirish.
Replay strategiyasi va topiklar versiyasining mavjud emasligi.
Idempotency va EOSsiz stavkalar/to’lovlar.

Yakunlar

Real-time striming - bu «boshqa transport» emas, balki domen voqealari, aniq SLO, ma’lumotlar shartnomalari, derazalar va holatlar, xavfsizlik va kuzatuv. iGaming uchun barqaror to’plam - Kafka + Flink/ksqlDB + Debezium + Materialized Views + Feature Store. U millisekundlik reaktsiyalar, onlayn/oflayn tahlillarning muvofiqligi va yukni oshirishda nazorat qilinadigan qiyinchiliklarni beradi.