Event-Streaming жана реалдуу убакыт маалыматтар

(Бөлүк: Технология жана инфраструктура)

Кыскача резюме

Event-Streaming - бул окуялар пайда болгон учурда аларды иштеп чыгуу жана жеткирүү. iGaming үчүн бул коюмдарга, депозиттерге, антифрод сигналдарына, жооптуу оюндун лимиттерине, турнирдик таблицаларга жана жеке офферлерге дароо жооп кайтарууну билдирет. Базалык кирпичтер: шина окуялар (Kafka/Pulsar), агымы кыймылдаткыч (Flink/ksqlDB/Spark Structured Streaming), CDC Транзакциялык DD (Debezium), онлайн-ML жана реалдуу убакыт аналитика үчүн Feature Store (материалдык түшүнүктөр, OLAP).

Бул iGaming маанилүү жерде

Antifrod & тобокелдик: <100-300 ms, жүрүм-турум үлгүлөрү, бөгөт коюу жана эскалация менен байланышта.
Жооптуу оюн: лимиттерди көзөмөлдөө, жоготуулардын ылдамдыгы, анормалдуу жүрүм-турум - реалдуу убакыт режиминде алерт жана авто чектөөлөр.
Төлөмдөр: статус желдеткичтери, webhooks PSP, smart-retry, баланстардын проекциялары, SLA "убакыт-коштомо".
Оюн иш-чаралар: турнир лидерлери эсептөө (sliding терезелер), Live оюндар раунддар, CRM/маркетинг үчүн реалдуу убакыт тасмалар.
Жекелештирүү: Online Ficks (RFM, propensity) → trigger кампаниялар, секунданын ичинде push/email.
Оперативдүү аналитика: p95/p99 latency, воронка кадамдарын конвертациялоо, платформанын ден соолук сигналдары.

Архитектуралык моделдер

Lambda vs Kappa

Lambda: batch (DWH/ETL) + агым (иш). Plus - ийкемдүүлүк жана "арзан" бет; минус - кош логика.
Kappa: баары - журнал агымы сыяктуу (Kafka). Плюс - бир код, окуялардын реиграсы; минус - инфраструктурага карата катуу талаптар.

Практика: оор реалдуу убакыт контурлары үчүн - Kappa; отчет/ML-окутуу үчүн - кошумча batch контур.

Conveyor окуялар (шилтеме)

1. Өндүрүүчүлөр: коюм/төлөм кызматтары домендик окуяларды жарыялайт (outbox → Kafka).
2. Шина: Kafka ачкычтар боюнча партиялары менен ('player _ id', 'bet _ id').
3. CDC: Debezium OLTP (балансы, лимиттери) агымына өзгөрүүлөрдү алып келет.
4. Агымы иштетүү: Flink/ksqlDB/Spark - агрегаттар, терезелер, CEP, join's.
5. Проекциялар: материалдаштырылган таблицалар (Kafka Streams state store/ksqlDB tables/Redis), OLAP (ClickHouse/Druid).
6. Керектөөчүлөр: антифрод, CRM, эскертмелер, дашборддор, триггер workflow.

Маалыматтар контракттары жана схемалар

Euro/Protobuf + Schema Registry: катуу келишимдер, backward-compatible миграция.
Версиялоо: 'домен. event. v{n}`; бузуучу өзгөртүүлөргө тыюу салуу.
PII: токенизациялоо/шифрлөө, жашыруу, purpose limitation (GDPR).

Жеткирүү семантикасы жана демпотенттик

At-least-once - де-факто стандарт (мүмкүн дубликат) → милдеттүү idempotent-handling.
Exactly-once стримингде: Kafka транзакциялык өндүрүүчүлөрү + EOS Flink/Streams; (акча/баланс).
Outbox + CDC: DD кызматынын бир чындык булагы, кош жазуу коргоо.
Dedup: ачкыч ('idempotency _ key'), TTL менен дедупликация таблицасы, upsert/merge.

Убактылуу терезелер жана "кеч" маалыматтар

• Tumbling - белгиленген уячалар (мисалы, айлануу мүнөтү).
• Hopping - кадам менен жылып (мисалы, терезе 5 мин кадам менен 1 мин).
• Session - активдүүлүгү боюнча (оюнчу сессиясы).
• Watermarks: event-time иштетүү, "кеч" кабыл алуу (lateness), DLQ/side-output.
• CEP (Complex Event Processing): "Андан кийин 3 мүнөттө B", "M секунданын ичинде N окуялар", "жокко чыгаруу/ордун толтуруу".

Абалы жана масштабы

Stateful операторлору: Агрегаттар/джойндор (RocksDB state backend) абалын кармап турат.
Changelog topics: ишенимдүүлүк жана калыбына келтирүү абалы.
Backpressure: auto ылдамдык жөнгө салуу, sink/ системасы боюнча чектөөлөр.
ачкычтарды бөлүштүрүү: ысык ачкычтар (heavy hitters) → key-salting, skew mitigation.

Мониторинг жана SLO

SLO агымы: p99 end-to-end latency (мисалы, ≤ 2 с), алгылыктуу керектөөчү lag, жеткиликтүүлүгү ≥ 99. 9%.
Метрика: throughput, партия боюнча lag, watermark delay, drop/late ratio, backpressure, busy time операторлору, GC/JVM.
Alerty: DLQ өсүшү, watermark артта калуу, EOS текшерүү пункттарынын ийгиликсиздиктери, онлайн/оффлайн режиминде.
Tracing: кореляциялык ID ('trace _ id', 'message _ id') продюсер-стрим-консюмер аркылуу.

Коопсуздук жана комплаенс

TLS/MTLS, ACL/RBAC боюнча топиктер/столдор, сезгич домендерди сегменттөө (төлөмдөр/CUS).
Транзитте/дискте PII шифрлөө; Vault/SOPS сырлары.
Data retention & locality: региондор боюнча сактоо (ЕБ, Түркия, LatAm), алып салуу саясаты.
Аудит: ким жарыяланган/окуган, сценарийлер ойнотулат.

Жогорку жеткиликтүүлүк жана DR

Kafka: `replication. factor ≥ 3`, `min. insync. replicas ',' acks = all ', DR үчүн кросс-аймактык репликация (MM2).
Flink/Streams: контролдонуучу релиздер үчүн мезгил-мезгили менен checkpoint + savepoint; HA-JobManager.
OLAP: сегменттердин репликациясы, read replicas; тесттер failover (оюн күнү).

Аткаруу жана тюнинг

Өндүрүүчүлөр: batching ('linger. ms`, `batch. size '), кысуу (lz4/zstd).
Consumers: туура '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 таблицалары, Kafka Streams state store, Redis for low latentity, ClickHouse/Druid/Pinot for OLAP.
Fichestor: Feast же өздүк - онлайн (Redis) + оффлайн (Parquet/BigQuery), консистенттүүлүк кепилдиги.

Дизайн үлгүлөрү

Outbox → Kafka: ар бир домен иш-чара бүтүм DD.
Сагалар: окуялар аркылуу ордун толтуруу; Оркестр - агым.
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 (Pseudo Code): AntiFrod эсеби менен 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 каттоо).
Жүктөө: максаттуу 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. Windows, watermark, late-policy жана DLQ/side outputs.
6. Акча жолдорунда EOS/демпотенттикти киргизүү.
7. lag, watermark, DLQ мониторинг жана алерттерди киргизүү.
8. HA/DR жана reprocessing жоболорун камсыз кылуу.
9. Жайгаштыруу Feature Store жана синхрондоштуруу онлайн/оффлайн.
10. Get game-day: аткарбагандыгы жана калыбына келтирүү.

Антипаттерндер

акылдуу саясат жок окуя-убакыт жана processing-убакыт аралаштыруу.
Жок схемасы governance → "сындырып" релиздер.
late маалыматтарды жана "ысык ачкычтарды" четке кагуу.
replay стратегиясы жана топик чыгаруу жоктугу.
idempotency жана EOS жок коюмдар/төлөмдөр.

Натыйжалары

Реалдуу убакыт агымы "башка транспорт" эмес, ой жүгүртүү жолу: домендик окуялар, так SLO, маалымат келишимдери, терезелер жана абал, коопсуздук жана байкоо жүргүзүү. iGaming туруктуу топтому үчүн - Kafka + Flink/ksqlDB + Debezium + Materialized Views + Feature Store. Бул миллисекунддук реакцияларды, онлайн/оффлайн аналитикасынын ырааттуулугун жана жүктүн өсүшүндө көзөмөлгө алынган татаалдыкты берет.