Realtaym-fid hodisalar: arxitektura va xavfsizlik

Real-time fid - bu geymifikatsiya, antifrod, CRM triggerlari va to’lovlari bo’lgan mahsulotlarning «qon aylanish tizimi». Uning cho’qqilar paytida oldindan aytib bo’lmaydigan darajada ishlashi, mukofotlarni takrorlamasligi va ma’lumotlardan qochishi uchun qat’iy arxitektura kerak: protokollar va shinalardan tortib imzo, idempotentlik, byudjet kaperlari va kuzatish darajasigacha.

1) Maqsad va talablar

Ishonchlilik: voqealarni minimal lag bilan yetkazib berish (p95 ≤ 250 ms ingest, p95 ≤ 1-2 s iste’molchiga).

Yetkazib berish: at-least-once transport + idempotentlik orqali mantiqiy exactly-once.

Tartib: qayta tartibga solish oynalari bilan kalitni (odatda’user _ id’) tartibga solish.

Xavfsizlik: MTLS, HMAC/JWT, kalitlarni rotatsiya qilish, replay/dublikatlardan himoya qilish, PII ni minimallashtirish.

Masshtab: gorizontal sharding, backpressure, rate limiting, DLQ/replay.

Boshqaruvchanligi: schema registry, version, ishlamay migratsiya.

Komplayens: audit (WORM), RG/KYC geytlar, geo-siyosat, GDPR/anonimlashtirish.

2) Tayanch arxitektura (qatlam-qatlam)

1. Producers (manbalar): o’yin serveri, hamyon/to’lov, KYC/AML, mijozlar SDK (web/iOS/Android).

2. API Gateway (Ingress): HTTP/gRPC qabul qilish, sxemani validatsiya qilish, autentifikatsiya qilish, HMAC/MTLS, vaqtni normallashtirish.

3. Queue/Stream: Kafka/Rabbit/Cloud Pub/Sub - buferlash, partiyalash’user _ id’.

4. Stream Processor: normalizator, boyitish, mavzularni yo’naltirish, anormallik/antibot bayroqlar, idempotent yozuvi.

5. Consumers: Rules/Scoring, Reward Orchestrator, CRM/CDP konnektorlar, antifrod, analitik sink’i.

6. Storage: xom voqealar (immutable), vitrinalar, idempotentlik indeksi, audit-jurnal.

7. Observability: metriklar, loglar, trastirovkalar, alertlar; panics → DLQ.

8. Admin Plane: schema registry, kalitlar/sirlar, RBAC/ABAC, ficheflaglar, replay-servis.

3) Yetkazib berish protokollari: qachon foydalanish kerak

HTTP/JSON (server-to-server vebxuklari): oddiy, mos, tashqi hamkorlar uchun yaxshi. HMAC + idempotentlik qoʻshish.

gRPC/Protobuf: past kechikish, qattiq sxemalar, ichki xizmatlar uchun bdi-strimlar.

WebSocket/SSE: mijozga push, peshqadamlar va taraqqiyotga UI obunalari.

CDC/Kafka Connect: manbalar biznes xizmatlari emas, balki BD/hamyonlar bo’lganda.

Tavsiya: tashqi perimetri - HTTP + HMAC + MTLS; ichida - gRPC/Protobuf.

4) Tadbir va konvensiya modeli

json
{
"event_id": "e_01HF3Z8Z7Q8Q2K",  "event_type": "bet",  "schema_version": "1. 3. 0",  "occurred_at": "2025-10-24T11:37:21Z",  "ingested_at": "2025-10-24T11:37:21. 183Z",  "key": { "user_id": "u_12345" },  "ctx": {
"session_id": "s_778",   "platform": "ios",   "geo": "TR",   "device_fp": "fp_4a1..."
},  "payload": {
"game_id": "slot_wolf",   "bet": 0. 5,   "win": 1. 25,   "currency": "EUR",   "provider": "GameCo"
},  "sig": {
"algo": "HMAC-SHA256",   "kid": "k_2025_10",   "ts": 1730061441,   "mac": "c7b7b3...f1"
}
}

Qoidalar:

Ikki vaqt:’occurred _ at’(manba) va’ingested _ at’(shlyuz). Soat driftiga 300 ± ruxsat bering.
Marshrutlash kaliti - bu tartibni belgilaydi (odatda’user _ id’).
PII faqat minimallashtirish tamoyili bo’yicha’ctx ’/’ payload’da; sezgir atributlar uchun - tokenizatsiya.

5) Yetkazib berish, tartib va idempotentlik

At-least-once transporti → dublikatlar va qayta tartibga solish mumkin.

Exactly-once mantig’i:’(event_id)’va/yoki’(user_id, source_seq)’bo’yicha noyob indeksi bo’lgan idempotentlik jadvalini saqlang; takrorlash - no-op.

SQL-eskiz:

sql
CREATE TABLE event_log (
event_id TEXT PRIMARY KEY,  user_id TEXT,  event_type TEXT,  occurred_at TIMESTAMPTZ,  payload JSONB
);

-- dubldan himoyalangan qoʻyish
INSERT INTO event_log(event_id, user_id, event_type, occurred_at, payload)
VALUES (:event_id,:user_id,:event_type,:occurred_at,:payload)
ON CONFLICT (event_id) DO NOTHING;

Tartib: protsessorda’user _ id’+ reordering window 60-120 s bo’yicha oqimni partiyalashtirish. Keyinchalik sodir bo’lgan hodisalar tuzatish funksiyalarini «qayta o’ynash» ga tushadi.

6) Backpressure va cho’qqilarni boshqarish

Token-bucket rate limiting на ingress (per-IP, per-partner, per-key).

Circuit breaker: 5xx ichki iste’molchilardan → degradatsiya (ixtiyoriy hodisalarning dropauti, navbatlar retray oraliqlarini oshiradi).

DLQ: doimiy xato xabarlar (singan sxema, imzo haqiqiy emas, imzo TTLdan oshib ketgan).

Replay server:’event _ id ’/vaqt diapazoni boʻyicha DLQdan tanlangan repablish.

7) Sxemalar va evolyutsiya: prodni qanday «sindirmaslik»

Schema Registry: JSON Schema/Protobuf; muvofiqlik siyosati: prodyuserlar uchun backward, konsumerlar uchun forward.

Version:’schema _ version’, major - faqat ficheflag va ikki marta yozuv (dual-write) orqali.

Kontraktlar: kanareya davridan keyin sxemani ilgari surish va green metrics.

Tekshirish qoidalarining YAML namunasi:

yaml compatibility:
enforce: true mode: backward blocked_fields:
- payload. ssn
- payload. card_number required_fields:
- event_id
- event_type
- occurred_at

8) Tahdidlar modeli va himoya

Xavf-xatarlar: tanani almashtirish, replay, PII sizib chiqish, kalitni buzish, schema-poisoning, DoS, MITM, signatura-stripping.

Himoya:

Perimetrda MTLS: qisqa muddatli mijoz sertifikatlari, CRL/OCSP.
Tananing HMAC-imzosi +’X-Timestamp’va TTL (± 300 s).
JWT (client credentials/OAuth2) - avtorizatsiya va skope cheklovlari uchun.
Kalit rotatsiyasi (KMS): «kid» sarlavhada; rotatsiya rejasi 30-90 kun; migratsiya oynasida ikki marta tekshirish.
Nonce/idempotentlik:’X-Request-Id’so’rovnoma-nojo’ya narsalar uchun (to’lovlar, bonuslar); TTL vaqtinchalik saqlang.
Content-Type pinning, max body size, allow-list IP/ASN kritik integratsiyalar uchun.
WORM-audit barcha kiruvchi raw-payload + sarlavhalar (oʻzgarmas saqlash).

HMAC tekshirish namunasi (psevdokod):

python body = request. raw_body ts = int(request. headers["X-Timestamp"])
assert abs(now() - ts) <= 300 # анти-replay kid = request. headers["X-Key-Id"]
secret = kms. fetch(kid)
mac = hmac_sha256(secret, body)
assert hmac_eq(mac, request. headers["X-Signature"])

9) Maxfiylik, PII va RG/KYC

Minimallashtirish: PII link-token orqali (5-15 daqiqaga) inlayn o’rniga uzatish; xom loglarda tahrir qilish/anonimlashtirish taqiqlangan - alohida PII-storanslardan foydalaning.

Kirish: yurisdiksiya va rol atributlari bo’yicha ABAC; barcha o’qishlar audit-jurnalga kiritiladi.

GDPR: Olib tashlash huquqini key-mapping orqali amalga oshirib, PIIni buzilmasdan oʻchiring.

RG/KYC: qimmatbaho mukofotlarni talab qiladigan voqealarni faqat haqiqiy KYC darajasi va «OK» RG bayroqlari bilan o’tkazib yuboring.

10) Kuzatuv va SLO

SLO (misol):

Ingest p95 ≤ 250 ms; end-to-end p95 ≤ 2 с; rad etish ≤ 0. 1 %/sutka.
Xato imzosi (HMAC/JWT) ≤ 0. umumiy oqimning 02%
DLQ fill rate ≤ 0. 1%; «dublikatlar» idempotentlikdan keyin ≤ 0. 005%.

Dashboard:

Manbalar boʻyicha RPS, p50/p95 latency, 4xx/5xx, imzo xatolari, time-skew.
Partitsiyalar bo’yicha Lag, qayta ishlash/sek, fill DLQ, retries, repley-hajmlar.
Sxemalar: versiya bo’yicha xabarlar ulushi, muvofiqlik buzilishi.
Xavfsizlik: rps-throttle chastotasi, circuit-breakers, IP/ASN anomaliyalari.

Alertlar (misollar):

SRM oqimi (bitta manbadan trafikning keskin oʻzgarishi).
Latentlik p95> maqsadli 5 min +, o’sish DLQ> X/min.
Xato imzolari> Y ppm,’X-Request-Id’takrorlanishi.
Drift soat> 120 s manba.

11) Ko’p mintaqa va nosozlikka chidamlilik

Active-Active mintaqalari, global routing (GeoDNS/Anycast), sticky-key po’user _ id’→ mintaqa.

Tanqidiy voqealar uchun kross-mintaqaviy replikatsion topik (pul, KYC).

Blast radius: tenant/brendlar bo’yicha izolyatsiya, alohida byudjet va kalitlar.

DR-reja: RPO ≤ 5 min, RTO ≤ 30 min; muntazam mashqlar.

12) Retenshn va replay siyosati

Xom hodisalar: 7-30 kun (qiymati bo’yicha), agregatlar/vitrinalar - uzoqroq.

Izohga faqat imzolangan runbook (kim, nima, nima, vaqt oraligʻi) orqali ruxsat berilgan.

Replay har doim analitik shaffoflik uchun’replayed = true’bayrogʻi bilan yangi stream-versiyaga oʻtadi.

13) Konfiguratsiya namunalari

Ingress (NGINX-uslub) limitlari:

nginx limit_req_zone $binary_remote_addr zone=req_limit:10m rate=300r/s;
limit_req zone=req_limit burst=600 nodelay;

client_max_body_size 512k;
proxy_read_timeout 5s;

Kafka (misol):

properties num. partitions=64 min. insync. replicas=2 acks=all retention. ms=604800000  # 7 days compression. type=zstd

Kalitlar uchun policy (KMS):

yaml rotation_days: 45 grace_period_days: 7 allow_algos: ["HMAC-SHA256"]
key_scopes:
- topic: "wallet_events"
producers: ["wallet-svc"]
consumers: ["ledger-svc","risk-svc"]

14) Real-time fidani ishga tushirish chek-varaqasi

Perimetrdagi MTLS, HMAC/JWT, kalitlar rotatsiyasi (’kid’).
Mantiqdagi idempotentlik (noyob kalitlar, upsert/ON CONFLICT).
’user _ id’, reordering window, replay-servis bo’yicha partiyalashtirish.
Schema registry + muvofiqlik siyosati; major-yangilanishlarda dual-write.
Rate limiting, circuit breakers, DLQ + qo’lda qichqiriq.
Kuzatish darajasi: SLO, imzo/yashirin/DLQ/lag.
PII/anonimlashtirish siyosati, ABAC, WORM auditi.
DR/ko’p mintaqa, feylover mashqlari.
Runbooks: hodisalar, belgi, sxemalar/kalitlarning qaytishi.

15) Mini-keys (sintetik)

Kontekst: turnirlarning eng yuqori cho’qqisi, 120 ta RPS ingress, 64 ta partiya, 2 ta Active-Active mintaqasi.

Jami 4 hafta davomida: ingest p95 210 ms, e2e p95 1. 6 s; DLQ 0. 05%; xato imzolari 0. 009%; dublikatlar idempotentlikdan keyin 0. 003%.

Hodisa: sherikning soati (9 daqiqa −) → anti-replay ko’tarilishi. Circuit breaker oqimni «bufer» endpointga o’tkazdi, partner-health CSMni xabardor qildi; NTP sinkidan so’ng - barcha konsumerlarga 12 daqiqalik deraza ko’rsatkichlari. Yo’qotishlar va ikki baravar to’lovlar yo’q.

16) Xulosa

Ishonchli real-time fid - bu «shunchaki vebxuk» emas. Bu aniq shartnomalarga ega qatlamli tizim: at-least-once transport + mantiqiy exactly-once, sxema-registrlar va versiyalash, MTLS/HMAC/JWT va kalitlar rotatsiyasi, backpressure/DLQ/replex, PII minimallashtirish va qat’iy audit. Ushbu amaliyotlarga rioya qilsangiz, siz gamifikatsiya, antifrod, CRM va to’lovlarni ishonchli tarzda qurishingiz mumkin bo’lgan tez, xavfsiz va oldindan aytib bo’ladigan voqealar oqimiga ega bo’lasiz.