Реалтайм-фид оқиғалар: сәулет және қауіпсіздік

Real-time оқиғалар фид - бұл геймификация, антифрод, CRM-триггерлер және төлемдері бар өнімдердің «қан айналымы жүйесі». Ол шыңдалған кезде алдын ала жұмыс істеуі үшін, наградаларды қайталамауы және деректермен жүрмеуі үшін, хаттамалар мен шиналардан бастап қол қоюға, идемпотенттілікке, бюджет-капердерге және бақылауға дейінгі қатаң архитектура қажет.

1) Мақсаттар мен талаптар

Сенімділік: минималды лагпен оқиғаларды жеткізу (p95 ≤ 250 мс ingest, p95 ≤ 1-2 с тұтынушыға дейін).

Жеткізу: at-least-once көлік + логикалық exactly-once демпотенттік арқылы.

Тәртібі: қайта реттеу терезелері бар кілт бойынша реттеу (әдетте 'user _ id').

Қауіпсіздік: MTLS, HMAC/JWT, кілттерді ротациялау, replay/көшірмелерден қорғау, PII азайту.

Масштабы: көлденең шардинг, backpressure, rate limiting, DLQ/реплика.

Басқарылуы: schema registry, нұсқалау, бос тұрусыз көші-қон.

Комплаенс: аудит (WORM), RG/KYC гейттер, гео-саясат, GDPR/анонимдеу.

2) Тірек сәулеті (қабат-қабат)

1. Producers (дереккөздер): ойын сервері, әмиян/төлем, KYC/AML, клиенттік SDK (web/iOS/Android).

2. API Gateway (Ingress): HTTP/gRPC қабылдау, схеманы валидациялау, аутентификация, HMAC/MTLS, уақытты қалыпқа келтіру.

3. Queue/Stream: Kafka/Rabbit/Cloud Pub/Sub - буферизация, 'user _ id' бойынша партиялану.

4. Stream Processor: қалыпқа келтіргіш, байыту, тақырыптарды бағыттау, анормалия/жалауларға қарсы, демпотенттік жазба.

5. Consumers: Rules/Scoring, Reward Orchestrator, CRM/CDP коннекторлары, антифрод, аналитикалық sink 'и.

6. Storage: шикі оқиғалар (immutable), витриналар, идемпотенттік индексі, аудит-журналы.

7. Observability: метрика, логи, трассировка, алерта; panics → DLQ.

8. Admin Plane: schema registry, кілттер/құпиялар, RBAC/ABAC, фичефлагтар, реплей-сервис.

3) Жеткізу хаттамалары: қашан пайдалану керек

HTTP/JSON (server-to-server): қарапайым, үйлесімді, сыртқы серіктестер үшін жақсы. HMAC + сәйкестік қосу.

gRPC/Protobuf: төмен кідіріс, қатаң схемалар, ішкі сервистер үшін bidi-стримдер.

WebSocket/SSE: push клиентке, UI-жазылымдар көшбасшылық және прогресс.

CDC/Kafka Connect: көздер бизнес-сервистер емес, ДБ/әмияндар болғанда.

Ұсыным: сыртқы периметр - HTTP + HMAC + MTLS; ішінде - gRPC/Protobuf.

4) Оқиға мен конвенцияның моделі

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"
}
}

Ережелер:

Екі уақыт: 'occurred _ at' (дереккөз) және 'ingested _ at' (шлюз). Сағат дрейфіне 300 с ± рұқсат етіңіз.
Бағыттау кілті - ретті анықтайтын нәрсе (әдетте 'user _ id').
PII тек 'ctx '/' payload' -те азайту қағидаты бойынша; сезімтал атрибуттар үшін - токенизация.

5) Жеткізу, тәртіп және іспеттілік

At-least-once көлік → дубликаттар мен қайта ретке келтіруге болады.

Exactly-once логикасы: '(event_id)' және/немесе '(user_id, source_seq)' бойынша бірегей индексі бар сәйкестік кестесін ұстаңыз; қайталау - no-op.

SQL-скетч:

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

-- қосарланудан қорғайтын кірістіру
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;

Тәртіп: процессорда 'user _ id' + reordering window 60-120 с бойынша ағынды партияландыру. Кейінірек келген оқиғалар түзету функцияларының «қайта ойнауына» (replay) түседі.

6) Backpressure және шыңдарды басқару

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

Circuit breaker: 5xx кезінде ішкі тұтынушылардан → деградация (міндетті емес оқиғалардың дропауты, кезектер ретрай аралықтарын ұлғайтады).

DLQ: үздіксіз қате хабарлар (сынған схема, қолтаңба дұрыс емес, қолтаңбаның TTL-і асып кеткен).

Replay service: 'event _ id '/уақыт ауқымы бойынша DLQ ішінен іріктелген репаблиш.

7) Сұлбалар және эволюция: сынықты қалай «сындырмау»

Schema Registry: JSON Schema/Protobuf; үйлесімділік саясаты: продюсерлер үшін backward, консумерлер үшін forward.

Нұсқалау: 'schema _ version', мажорлық - тек фичефлаг және қос жазба (dual-write) арқылы.

Келісімшарттар: канареялық кезеңнен кейін схеманы жылжыту және green metrics.

Тексеру ережесінің YAML үлгісі:

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

8) Қатерлер моделі және қорғау

Қауіп-қатерлер: денені ауыстыру, қайталау (replay), PII ағуы, кілттің компрометациясы, schema-poisoning, DoS, MITM, сигнатура-stripping.

Қорғау:

MTLS периметрде: қысқа мерзімді клиенттік сертификаттар, CRL/OCSP.
HMAC-дененің қолы + 'X-Timestamp' және TTL (± 300 с).
JWT (client credentials/OAuth2) - scope бойынша авторизациялау және шектеу үшін.
Кілттердің айналымы (KMS): 'kid' тақырыбында; ротациялау жоспары 30-90 күн; көші-қон терезесінде екі рет тексеру.
Nonce/іспеттілік: жанама сұрау үшін 'X-Request-Id' (төлемдер, бонустар); TTL уақытына сақтаңыз.
Content-Type pinning, max body size, allow-list IP/ASN сындарлы интеграциялар үшін.
WORM-аудит барлық кіріс raw-payload + тақырыптар (өзгермейтін сақтау орны).

HMAC тексеру мысалы:

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) Құпиялылық, PII және RG/KYC

Барынша азайту: PII инлайн орнына сілтеме-токен бойынша (5-15 минутқа) беру; шикі логтарда өңдеуге/анонимдеуге тыйым салынады - жеке PII-сторанцтарды пайдаланыңыз.

Қол жеткізу: юрисдикция және рөл атрибуттары бойынша ABAC; барлық оқулар - аудит-журналға.

GDPR: жою құқығын key-mapping арқылы іске асырып, PII-ді оқиға фактілерін бұзбай өшіріңіз.

RG/KYC: бағалы наградаларды беруді талап ететін оқиғаларды тек қана KYC-деңгейінде және «ОК» RG-жалауларында өткізіп жіберіңіз.

10) Бақылау және SLO

SLO (мысал):

Ingest p95 ≤ 250 мс; end-to-end p95 ≤ 2 с; бас тарту ≤ 0. 1 %/тәулік.
Қолтаңба-қателер (HMAC/JWT) ≤ 0. жалпы ағынның 02% -ы.
DLQ fill rate ≤ 0. 1%; ≤ ұқсастығынан кейін «телнұсқалар» 0. 005%.

Дашборд:

RPS дереккөздер бойынша, p50/p95 latency, 4xx/5xx, қолтаңбалар-қателер, time-skew.
Партия бойынша Lag, қайта өңдеу/сек, fill DLQ, retries, реплика-көлемдер.
Схемалар: нұсқалар бойынша хабарламалар үлесі, үйлесімділіктің бұзылуы.
Қауіпсіздік: rps-throttle жиілігі, circuit-breakers, IP/ASN ауытқулары.

Алерттар (мысалдар):

SRM ағыны (бір көзден трафиктің күрт ауытқуы).
Жасырындылық p95> мақсатты 5 мин +, өсу DLQ> X/min.
Қате қолтаңбалар> Y ppm, 'X-Request-Id' қайталау күйі.
Drift сағат> 120 с көзінде.

11) Мульти-өңір және істен шығу тұрақтылығы

Active-Active аймақтары, жаһандық роутинг (GeoDNS/Anycast), sticky-key 'user _ id' → аймағы.

Сыни оқиғалар үшін кросс-өңірлік репликациялық топик (ақшалай, KYC).

Blast radius: тенанттар/брендтер бойынша оқшаулау, жеке бюджеттер мен кілттер.

DR-жоспар: RPO ≤ 5 мин, RTO ≤ 30 мин; тұрақты репетициялар.

12) Ретеншн және реплея саясаты

Шикі оқиғалар: 7-30 күн (құны бойынша), агрегаттар/витриналар - ұзақ.

Реплика тек қол қойылған runbook (кім, не, неге, уақыт ауқымы) бойынша рұқсат етілген.

Реплика әрқашан талдамалық ашықтық үшін 'replayed = true' жалаушасы бар жаңа stream-version жүйесіне өтеді.

13) Конфигурация мысалдары

Ingress (NGINX-стиль) лимиттері:

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 (мысал):

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

Кілттер үшін 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 іске қосу чек-парағы

Периметрдегі MTLS, HMAC/JWT, кілттердің ротациясы ('kid').
Логикадағы сәйкестік (бірегей кілттер, upsert/ON CONFLICT).
'user _ id', reordering window, реплика-сервис бойынша партиялану.
Schema registry + үйлесімділік саясаты; major-ауқымдарда dual-write.
Rate limiting, circuit breakers, DLQ + қолмен реву.
Бақылау қабілеті: SLO, қолтаңба/жасырындылық бойынша алерталар/DLQ/lag.
PII/анонимдеу саясаты, ABAC, WORM аудиті.
DR/мульти-аймақ, фейловер дайындығы.
Runbooks: оқиғалар, репликалар, схемалар/кілттер.

15) Шағын кейс (синтетикалық)

Контекст: турнирлердің шыңы, RPS ingress-ке 120, 64 партия, Active-Active аймағының 2.

4 аптадағы жиыны: ingest p95 210 мс, e2e p95 1. 6 с; DLQ 0. 05%; қате қолтаңбалары 0. 009%; Сәйкестіктен кейінгі телнұсқалар 0. 003%.

Оқиға: Серіктес сағаттар дрейфі (− 9 мин) → anti-replay. Circuit breaker ағынды «буферлік» эндпоинтке ауыстырған, partner-health CSM-ге хабарлаған; NTP синктен кейін - барлық консьюмерлерге 12 мин терезе репликасы. Шығындар мен қосарланған төлемдер жоқ.

16) Түйіндеме

Сенімді real-time фид - бұл «жай вебхактар» емес. Бұл нақты келісімшарттары бар қабатты жүйе: at-least-once көлік + логикалық exactly-once, схема-тіркелімдер және нұсқалау, MTLS/HMAC/JWT және кілттерді ротациялау, backpressure/DLQ/реплика, PII-ні барынша азайту және қатаң аудит. Осы тәжірибелерді сақтай отырып, сіз ойынды, антифродты, CRM және төлемдерді сенімді түрде құруға болатын оқиғалардың жылдам, қауіпсіз және болжамды ағынын аласыз.