Realtaym-fid hadisələr: memarlıq və təhlükəsizlik

Real-time feed hadisələri gamifikasiya, antifrod, CRM tetikleyiciləri və ödənişləri olan məhsulların «qan dövranı sistemidir». Onun zirvələrdə proqnozlaşdırıla bilən işləməsi, mükafatları təkrarlamaması və məlumatlardan keçməməsi üçün ciddi bir memarlıq lazımdır: protokollardan və şinlərdən imza, idempotentlik, büdcə kaperləri və müşahidə qabiliyyətinə qədər.

1) Məqsədlər və tələblər

Etibarlılıq: minimum lag ilə tədbir (p95 ≤ 250 ms ingest, p95 ≤ 1-2 s istehlakçıya).

Çatdırılma: at-least-once nəqliyyat + idempotentlik vasitəsilə məntiqi exactly-once.

Sifariş: Yenidən tənzimləmə pəncərələri ilə açar (adətən 'user _ id') qaydası.

Təhlükəsizlik: MTLS, HMAC/JWT, açar rotasiyası, replay/dublikat qorunması, PII-nin minimuma endirilməsi.

Miqyaslı: üfüqi sharding, backpressure, rate limiting, DLQ/replay.

Nəzarət: schema registry, version, fasiləsiz miqrasiya.

Komplayens: audit (WORM), RG/KYC geytalar, geo-siyasətlər, GDPR/anonimləşdirmə.

2) Dayaq arxitekturası (qat-qat)

1. Producers (mənbələr): oyun serveri, cüzdan/ödəniş, KYC/AML, müştəri SDK (web/iOS/Android).

2. API Gateway (Ingress): HTTP/gRPC qəbulu, sxem validasiyası, autentifikasiya, HMAC/MTLS, vaxtın normallaşdırılması.

3. Queue/Stream: Kafka/Rabbit/Cloud Pub/Sub - bufer, partizan 'user _ id'.

4. Stream Processor: normallaşdırıcı, zənginləşdirici, mövzu marşrutu, anormallik/anti-bayraqlar, idempotent qeyd.

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

6. Saxlama: xam hadisələr (immutable), vitrinlər, idempotentlik indeksi, audit jurnalı.

7. Observability: metriklər, loglər, izlər, alertlər; panics → DLQ.

8. Admin Plane: schema registry, açarları/sirləri, RBAC/ABAC, fitness, replay xidməti.

3) Çatdırılma protokolları: nə zaman istifadə etmək lazımdır

HTTP/JSON (server-to-server vebhuk): sadə, uyğun, xarici tərəfdaşlar üçün yaxşı. HMAC + idempotentlik əlavə edin.

gRPC/Protobuf: aşağı gecikmə, sərt sxemlər, daxili xidmətlər üçün bdi axınları.

WebSocket/SSE: müştəri push, aparıcı bordlara UI abunə və tərəqqi.

CDC/Kafka Connect: mənbələr biznes xidmətləri deyil, BD/cüzdan olduqda.

Tövsiyə: xarici perimetr - HTTP + HMAC + MTLS; daxilində - gRPC/Protobuf.

4) Hadisə və 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"
}
}

Qaydalar:

İki vaxt: 'occurred _ at' (mənbə) və 'ingested _ at' (şluz). 300 saata ± sürüklənməyə icazə verin.
Marşrutlaşdırma açarı sıranı təyin edən şeydir (adətən 'user _ id').
PII yalnız 'ctx '/' payload' minimallaşdırma prinsipi üzrə; həssas atributlar üçün - tokenizasiya.

5) Çatdırılma, sifariş və idempotentlik

At-least-once nəqliyyat → təkrarlanması və yenidən nizamlanması mümkündür.

Exactly-once məntiqi: unikal '(event_id)' və/və ya '(user_id, source_seq)' indeksi ilə idempotentlik cədvəlini saxlayın; təkrar - 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
);

-- dubl qorunması ilə insert
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;

Sifariş: 'user _ id' + reordering window 60-120s prosessor axını partizan. Daha sonra baş verən hadisələr düzəliş funksiyalarının «təkrar oyununa» (replay) düşür.

6) Backpressure və zirvə nəzarət

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

Circuit breaker: daxili istehlakçılardan 5xx → deqradasiya (isteğe bağlı hadisələrin dropautu, növbələr gecikmə intervallarını artırır).

DLQ: Permanent səhv mesajlar (sınıq sxem, imza qeyri-sabit, TTL-dən artıq imza).

Replay Service: 'event _ id '/zaman diapazonu ilə DLQ-dən seçici repablich.

7) Sxemlər və təkamül: produ necə «sındırmamaq»

Schema Registry: JSON Schema/Protobuf; uyğunluq siyasəti: prodüserlər üçün backward, məsləhətçilər üçün forward.

Version: 'schema _ version', major - yalnız ficheflag və dual-write vasitəsilə.

Müqavilələr: Kanarya dövründən sonra sxemin təşviqi və yaşıl metrika.

YAML nümunə yoxlama qaydaları:

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

8) Təhdid və müdafiə modeli

Təhdidlər: bədən dəyişdirilməsi, təkrar (replay), PII sızması, açar kompromasiyası, schema-poisoning, DoS, MITM, signatura-stripping.

Müdafiə:

MTLS perimetrdə: qısamüddətli müştəri sertifikatları, CRL/OCSP.
HMAC-bədən imzası + 'X-Timestamp' və TTL (± 300 s).
JWT (client credentials/OAuth2) - avtorizasiya və scope məhdudiyyətləri üçün.
Açarların rotasiyası (KMS): başlıqda 'kid'; 30-90 gün rotasiya planı; miqrasiya pəncərəsində ikiqat yoxlama.
Nonce/idempotentlik: yan sorğular üçün 'X-Request-Id' (ödənişlər, bonuslar); TTL müddətinə saxlayın.
Content-Type pinning, max body size, allow-list IP/ASN kritik inteqrasiyalar üçün.
Bütün daxil olan raw-payload + başlıqların WORM auditi (dəyişməz saxlama).

HMAC yoxlama nümunəsi (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) Gizlilik, PII və RG/KYC

Minimallaşdırma: PII link-tokenlə (5-15 dəqiqə) link əvəzinə ötürülür; xam loglarda redaktə/anonimləşdirmə qadağandır - ayrı-ayrı PII storans istifadə edin.

Giriş: yurisdiksiya və rol atributları üzrə ABAC; bütün oxunmalar audit jurnalına daxil edilir.

GDPR: silinmə hüququ hadisələri pozmadan PII silmək üçün key-mapping vasitəsilə həyata keçirilir.

RG/KYC: qiymətli mükafatların verilməsini tələb edən hadisələri yalnız etibarlı KYC səviyyəsində və «OK» RG bayraqlarında buraxın.

10) Müşahidə və SLO

SLO (nümunə):

Ingest p95 ≤ 250 ms; end-to-end p95 ≤ 2 с; imtina ≤ 0. 1 %/gün.
İmza səhvləri (HMAC/JWT) ≤ 0. ümumi axının 02%.
DLQ fill rate ≤ 0. 1%; «dublikatlar» idempotentlik sonra ≤ 0. 005%.

Daşbord:

RPS mənbələri, p50/p95 latency, 4xx/5xx, imzalar-səhvlər, time-skew.
Partisitlər üzrə Lag, emal/san, fill DLQ, retries, replay-həcmlər.
Sxemlər: versiyalara görə mesajların payı, uyğunluq pozuntuları.
Təhlükəsizlik: rps-throttle tezliyi, circuit-breakers, IP/ASN anomaliyaları.

Alertlər (nümunələr):

SRM axını (bir mənbədən kəskin trafik çarpazlığı).
Latentity p95> hədəf 5 min +, boy DLQ> X/min.
İmzalar-səhvlər> Y ppm, 'X-Request-Id' təkrarlarının artması.
Drift saat> 120 s mənbə.

11) Multi-region və fasilə müqaviməti

Active-Active regionlar, qlobal marşrutlaşdırma (GeoDNS/Anycast), sticky-key 'user _ id' → region.

Kritik hadisələr (pul, KYC) üçün cross-regional replikasiya topik.

Blast radius: tenant/marka izolyasiyası, ayrı-ayrı büdcələr və açarlar.

DR planı: RPO ≤ 5 dəq, RTO ≤ 30 dəq; müntəzəm məşqlər.

12) Retenshn və replia siyasətləri

Xam hadisələr: 7-30 gün (qiymətə), aqreqatlar/vitrinlər - daha uzun.

Replay yalnız imzalanmış runbook ilə icazə verilir (kim, nə, niyə, zaman aralığı).

Replay həmişə analitik şəffaflıq üçün 'replayed = true' bayrağı ilə yeni stream-versiyaya gedir.

13) Konfiqurasiya nümunələri

Ingress (NGINX-stil) limitləri:

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 (nümunə):

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

Açar siyasəti (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) Check-list start real-time feed

MTLS perimetri, HMAC/JWT, açar rotasiyası ('kid').
Məntiqə idempotentlik (unikal açarlar, upsert/ON CONFLICT).
'user _ id', reordering window, replay servisi ilə partizanlaşdırma.
Schema registry + uyğunluq siyasəti; major yeniləmələrdə dual-write.
Rate limiting, circuit breakers, DLQ + əl review.
Müşahidə: SLO, imza/gizlilik/DLQ/lag.
PII/anonimləşdirmə siyasəti, ABAC, WORM audit.
DR/multi-region, feylover məşqləri.
Runbooks: hadisələr, replay, sxemləri/açarları geri.

15) Mini case (sintetik)

Kontekst: turnirlərin zirvəsi, 120 RPS ingress, 64 partiya, 2 Active-Active regionu.

Cəmi 4 həftə ərzində: ingest p95 210 ms, e2e p95 1. 6 s; DLQ 0. 05%; səhv imzalar 0. 009%; İdempotentlikdən sonra dublikatlar 0. 003%.

Hadisə: partnyorda saat sürüklənməsi (− 9 dəq) → anti-replay sıçrayışı. Circuit breaker axını «bufer» end nöqtəsinə çevirdi, partner-health CSM-ə xəbərdarlıq etdi; NTP sink sonra - pəncərə replica 12 min bütün müştəri. Heç bir itki və ikiqat ödəniş yoxdur.

16) Xülasə

Etibarlı real-time fid «sadəcə vebhuk» deyil. Bu aydın müqavilələr ilə laylı sistemdir: at-least-once nəqliyyat + məntiqi exactly-once, sxem-registrlər və versiyalaşdırma, MTLS/HMAC/JWT və açar rotasiyası, backpressure/DLQ/replay, PII minimallaşdırılması və ciddi audit. Bu təcrübələrə riayət etməklə, oyunlaşdırma, antifrod, CRM və ödənişləri inamla qura biləcəyiniz sürətli, təhlükəsiz və proqnozlaşdırıla bilən bir hadisə axını əldə edəcəksiniz.