Реалтайм-фид окуялары: архитектура жана коопсуздук

Real-Time Fid окуялар - бул "кан айлануу системасы" gamification, antifrod, CRM триггерлер жана төлөмдөр менен буюмдар болуп саналат. Ал чокуларда алдын ала иштеши үчүн, сыйлыктарды кайталабашы жана маалыматтар менен агып кетпеши үчүн, катуу архитектура керек: протоколдордон жана шиналардан кол коюуга чейин, демпотенттик, бюджет-каперлер жана байкоо жүргүзүү.

1) Максаттар жана талаптар

Ишенимдүүлүк: минималдуу лагдар менен иш-чараларды жеткирүү (p95 ≤ 250 ms ingest, p95 ≤ 1-2 s керектөөчүгө чейин).

Жеткирүү: 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 connectors, antifrod, аналитикалык sink '.

6. Storage: чийки окуялар (immutable), витриналар, демпотенттик индекси, аудит журналы.

7. Observability: метрика, Логи, Tracking, Алерт; panics → DLQ.

8. Admin Plane: схема каттоо, ачкычтар/сырлар, RBAC/ABAC, phicheflagy, replay кызматы.

3) жеткирүү протоколдору: качан колдонуу керек

HTTP/JSON (server-to-server webhook): жөнөкөй, шайкеш, тышкы өнөктөштөр үчүн жакшы. HMAC + боштондук кошуу.

gRPC/Protobuf: төмөн кечигүү, катуу схемалар, ички кызматтар үчүн биди-агымдар.

WebSocket/SSE: кардарга басуу, лидерлик такталарына жана прогресске UI жазылуу.

CDC/Kafka Connect: качан булактар бизнес кызматтары эмес, DD/капчыктар.

Сунуш: тышкы периметри - 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 кызматы: 'event _ id '/убакыт диапазону боюнча DLQ тандоо repablish.

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 текшерүү мисал (psevdocode):

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) Privacy, PII жана RG/KYC

Минималдаштыруу: PII шилтеме-токен аркылуу берүү (5-15 мүнөт) ордуна онлайн; чийки логдордо редакторлоо/анонимдештирүүгө тыюу салынат - айрым PII-storans колдонуңуз.

Access: ABAC юрисдикция жана ролу атрибуттары боюнча; бардык окуулар - аудит журналына.

GDPR: алып салуу укугу окуя чындыктарды сындырып жок PII өчүрүү үчүн негизги-картинки аркылуу ишке ашырылат.

RG/KYC: баалуу сыйлыктарды берүүнү талап кылган иш-чаралар, бир гана тастыкталган KYC-деъгээлинде жана RG-желектери "OK" менен сагынам.

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, кол-каталар, убакыт-skew.
Lag партиялары, кайра иштетүү/сек, fill DLQ, retries, реплика-көлөмү.
Схемалар: версиялар боюнча билдирүүлөрдүн үлүшү, шайкештиктин бузулушу.
Коопсуздук: rps-throttle жыштыгы, circuit-breakers, IP/ASN аномалиялар.

Алерталар:

SRM агымы (бир булактан жол кескин бурмалоо).
Latentity p95> максаттуу 5 мин +, өсүү DLQ> X/мин.
Кол тамгалар-каталар> Y ppm, 'X-Request-Id' кайталоо.
Drift саат> 120 с булакта.

11) Көп аймак жана бузулууга туруктуулук

Active-Active региондор, глобалдык роутинг (GeoDNS/Anycast), sticky-key 'user _ id' → аймак.

Critical окуялар үчүн кросс-аймактык репликация топик (акча, KYC).

Blast radius: Тенанттар/бренддер боюнча изоляция, жеке бюджеттер жана ачкычтар.

DR-план: RPO ≤ 5 мин, RTO ≤ 30 мин; үзгүлтүксүз репетициялар.

12) Retenshna жана реплика саясаты

Чийки окуялар: 7-30 күн (наркы боюнча), агрегаттар/дүкөндөр - узак.

реплика гана кол runbook боюнча жол берилет (ким, эмне үчүн, убакыт диапазону).

Реплика ар дайым аналитикалык ачык-айкындуулук үчүн 'replayed = true' желеги менен жаңы агым версиясына барат.

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

Ачкычтар үчүн саясат (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 ишке киргизүү реалдуу убакыт пайда

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

15) Mini Case (синтетикалык)

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

Бардыгы 4 жума ичинде: ingest p95 210 мс, e2e p95 1. 6 с; DLQ 0. 05%; кол-ката 0. 009%; демпотенттиктен кийинки дубликаттар 0. 003%.

Окуя: өнөктөш саат Driff (− 9 мин) → anti-replay. Circuit breaker "буфердик" пунктка агымын которгон, өнөктөш-ден соолук CSM кабарлаган; NTP Синк кийин - терезе Replica 12 мүнөт бардык Консумерлер. Жоготуулар жана кош төлөмдөр жок.

16) Резюме

Ишенимдүү Real-Time Fid - бул "жөн эле Webhook" эмес. Бул так келишимдер менен катмарлуу система болуп саналат: at-least-once транспорт + логикалык exactly-once, схема-реестрлер жана версиялоо, MTLS/HMAC/JWT жана ачкычтарды айлантуу, backpressure/DLQ/реплика, PII минималдаштыруу жана катуу аудит. Бул тажрыйбаларды сактоо менен, сиз ишенимдүү оюн курууга болот тез, коопсуз жана алдын ала иш-чаралардын агымын, antifrod, CRM жана төлөмдөр.