Evenimente feed în timp real: arhitectură și securitate

Hrana pentru evenimente în timp real este un „sistem circulator” de produse cu gamificare, antifraudă, declanșatoare și plăți CRM. Pentru ca acesta să funcționeze previzibil la vârfuri, nu să dupliceze premii și să nu scurgă date, este necesară o arhitectură strictă: de la protocoale și autobuz la semnătură, idempotență, privatizări bugetare și observabilitate.

1) Obiective și cerințe

Fiabilitate: livrarea evenimentelor cu un decalaj minim (p95 ≤ 250 ms ingera, p95 ≤ 1-2 s la consumator).

Livrare: cel puțin o dată transport + logic exact-o dată prin idempotence.

Comandă: comandă prin cheie (de obicei "user _ id') cu reordonarea ferestrelor.

Securitate: MTLS, HMAC/JWT, rotație cheie, reluare/protecție duplicat, PII minimizare.

Scală: sharding orizontal, backpressure, limitarea ratei, DLQ/reluare.

Posibilitate de administrare: registru schemă, versioning, migrații fără timpi morți.

Conformitate: audit (WORM), porți RG/KYC, geo-politici, GDPR/anonimizare.

2) Arhitectura de referință (strat cu strat)

1. Producători (surse): server de joc, portofel/plată, KYC/AML, SDK-uri client (web/iOS/Android).

2. API Gateway (Ingress): recepție HTTP/gRPC, validare schemă, autentificare, HMAC/MTLS, normalizarea timpului.

3. Coadă/Stream: Kafka/Rabbit/Cloud Pub/Sub - tamponare, partiționare prin 'user _ id'.

4. Procesor Stream: normalizator, îmbogățire, rutare subiect, steaguri anomalie/anti-boți, înregistrare idempotent.

5. Consumatori: Reguli/Scoring, Recompensă Orchestrator, conectori CRM/CDP, anti-fraudă, chiuvetă analitică "și.

6. Stocare: evenimente imuabile, storefronturi, index pentru idempotency, jurnal de audit.

7. Observabilitate: valori, busteni, urme, alerte; Intră în panică → DLQ.

8. Admin Plane: registru schema, chei/secrete, RBAC/ABAC, phicheflags, reluare serviciu.

3) Protocoale de livrare: când să utilizați ce

HTTP/JSON (webhookuri server-to-server): simple, compatibile, bune pentru partenerii externi. Adăugați idempotența HMAC +.

gRPC/Protobuf: latență scăzută, scheme stricte, fluxuri bidi pentru servicii interne.

WebSocket/SSE: apăsați la client, abonamente UI la clasamente și progres.

CDC/Kafka Connect: atunci când sursele sunt baze de date/portofele, nu servicii de afaceri.

Recomandare: perimetru exterior - HTTP + HMAC + MTLS; interior - gRPC/Protobuf.

4) Modelul evenimentului și al convenției

json
{
„event_id": „e_01HF3Z8Z7Q8Q2K,” „event_type": „pariu”, „schema_version": „1. 3. 0”, „occurred_at": „2025-10-24T11:37:21Z,” „ingested_at": „2025-10-24T11:37:21. 183Z,” „cheie”: {„user_id": „u_12345”}, „ctx”: {
„session_id": „s_778,” „platformă”: „ios”, „geo”: „TR”, „device_fp": „fp_4a1...”
}, „sarcină utilă”: {
"game_id": "slot_wolf," "pariu": 0. 5, „victorie”: 1. 25, „monedă”: „EUR”, „furnizor”: „GameCo”
}, „dig”: {
"algo": "HMAC-SHA256," "copil": "k_2025_10," "ts': 1730061441", mac ":" c7b7b3... f1 "
}
}

Reguli:

Cele două timpuri sunt 'happened _ at' (sursă) și' ingested _ at '(gateway). Permiteți ceasului să derivă ± 300 s.
Cheia de rutare este ceea ce determină ordinea (de obicei "user _ id').
PII numai în „ctx ”/„ sarcină utilă” pe principiul minimizării; pentru atribute sensibile, tokenizare.

5) Livrare, comandă și idempotence

Cel puțin o dată transport → duplicate și reordonare sunt posibile.

Logică exactă: păstrați un tabel de idempotență cu un indice unic pe „(event_id)” și/sau „(user_id, source_seq)”; repet - no-op.

Schiță SQL:

sql
CREAȚI TABELUL event_log (
event_id TEXT CHEIE PRINCIPALĂ, TEXT user_id, TEXT event_type, occurred_at TIMESTAMPTZ, sarcină utilă JSONB
);

- inserție dublu protejată
INTRODUCEȚI ÎN  ( , , , sarcină utilă)
VALORI (:event_id,:user_id,:event_type,:occurred_at,:payload)
PRIVIND CONFLICTUL (event_id) NU FACE NIMIC;

Ordine: partiționarea fluxului prin 'user _ id' + reordonarea ferestrei 60-120 sec în procesor. Mai târziu, evenimentele care vin în toamna în „reluarea” funcțiilor corective.

6) Backpressure și managementul vârfului

Rata token-bucket de limitare a pătrunderii на (per-IP, per-partener, per-cheie).

Întrerupător de circuit: cu 5xx de la consumatorii interni, → de degradare (abandonul evenimentelor opționale, cozile cresc intervalele de retractare).

DLQ: mesajele permanent eronate (bitmap, semnătura invalidă, semnătura TTL depășită).

Reluare serviciu: Selectiv DLQ reluare de 'event _ id'/interval de timp.

7) Scheme și evoluție: cum să nu „rupă” prod

Schema de registru: JSON Schema/Protobuf; politici de compatibilitate: înapoi pentru producători, înainte pentru consumatori.

Versioning: 'schema _ version', major - numai prin ficheflag și dublu-write (dual-write).

Contracte: promovarea schemei după perioada canară și măsurători verzi.

Regula de validare a exemplului YAML:

compatibilitate yaml:
aplicare: mod adevărat: blocked_fields înapoi:
- sarcină utilă. ssn
- sarcină utilă. card_number required_fields:
- event_id
- event_type
- occurred_at

8) Model de amenințare și protecție

Amenințări: spoofing corp, reluare, scurgere PII, compromis cheie, schema-otrăvire, DoS, MITM, semnătură-stripping.

Protecție:

MTLS pe perimetru: certificate client pe termen scurt, CRL/OCSP.
Semnătura corpului HMAC + „X-Timestamp” și TTL (± 300 s).
JWT (client credentials/OAuth2) - pentru autorizare și restricții de aplicare.
Rotație cheie (KMS): „copil” în antet; plan de rotație 30-90 de zile; verificare dublă în fereastra de migrare.
Nonce/idempotency: "X-Request-Id' pentru solicitări secundare (plăți, bonusuri); păstrează TTL pentru o vreme.
Tip de conținut pinning, dimensiunea maximă a corpului, permite lista IP/ASN pentru integrări critice.
Auditul WORM al tuturor sarcinilor brute + anteturilor primite (stocare neschimbabilă).

Exemplu de testare HMAC (pseudo code):

corp python = cerere. raw_body ts = int (cerere. anteturi [” X-Timestamp”])
asert abs (now () - ts) <= 300 # анти -replay kid = request. anteturi ["X-Key-Id']
secret = kms. fetch (copil)
mac = hmac_sha256 (secret, corp)
afirma hmac_eq (mac, cerere. anteturi [” Semnătura X”])

9) Confidențialitate, PII și RG/KYC

Minimizare: transfer PII prin jeton (timp de 5-15 minute) în loc de inline; editarea/anonimizarea în jurnalele brute este interzisă - utilizați pagini PII separate.

Acces: ABAC pe jurisdicție și atribute de rol; toate citește - la jurnalul de audit.

GDPR: exercitați dreptul de a șterge prin intermediul cartografierii cheilor pentru a șterge PII fără a rupe faptele evenimentelor.

RG/KYC: Evenimente care necesită recompense valoroase, săriți numai cu nivelul KYC valabil și steagurile RG „OK”.

10) Observabilitate și SLO

SLO (exemplu):

Ingera p95 ≤ 250 ms; end-to-end p95 ≤ 2 с; eșecul ≤ 0. 1 %/zi.
Semnătură eroare (HMAC/JWT) ≤ 0. 02% din fluxul total.
Rata de umplere DLQ ≤ 0. 1%; „duplicate” după idempotență ≤ 0. 005%.

Tablou de bord:

RPS după sursă, latență p50/p95, 4xx/5xx, semnături de eroare, timp-înclinare.
Lag de partid, procesare/sec, umple DLQ, retries, reluarea volumelor.
Scheme: partajarea mesajelor după versiune, încălcări ale compatibilității.
Siguranță: rată de accelerație rps, întrerupătoare de circuit, anomalii IP/ASN.

Alerte (exemple):

SRM a fluxului (denaturarea bruscă a traficului dintr-o singură sursă).
Latenţă p95> ţintă 5 min +, creştere DLQ> X/min.
Semnături de eroare> Y ppm, "X-Request-Id' reluare spike.
Ore de derivă> 120 s la sursă.

11) Multi-regiune și toleranță la erori

Regiuni active, rutare globală (GeoDNS/Anycast), tasta lipicioasă prin "user _ id' → regiune.

Subiect de replicare transregională pentru evenimente critice (monetare, KYC).

Raza exploziei: izolarea de către chiriași/mărci, bugete individuale și chei.

DR-plan: RPO ≤ 5 min, RTO ≤ 30 min; repetiţii regulate.

12) Politici de păstrare și reluare

Evenimente brute: 7-30 de zile (prin cost), agregate/vitrine - mai mult.

Replay este permis numai de un runbook semnat (care, ce, de ce, intervalul de timp).

Replay merge întotdeauna la o nouă versiune de stream cu 'relayed = true' steag pentru transparență analitică.

13) Exemple de configurare

Limite de intrare (stil 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 (exemplu):

proprietăți num. partiții = 64 min. insync. replici = 2 acks = toată retenția. ms = 604800000 # 7 zile de compresie. type = zstd

Politica pentru chei (KMS):

yaml rotation_days: 45 grace_period_days: 7 allow_algos: [„HMAC-SHA256”]
key_scopes:
- subiect: „wallet_events”
producători: ["portofel-svc']
consumatori: [„ledger-svc',” risc-svc']

14) Lista de verificare a lansării în timp real

MTLS pe perimetru, HMAC/JWT, rotație cheie ('kid').
Idempotence pe logica (chei unice, upsert/ON CONFLICT).
Partiționarea prin 'user _ id', reordonarea ferestrei, serviciul de reluare.
Registru schema + politici de compatibilitate; dual-write pentru actualizări majore.
Limitarea ratei, întrerupătoare de circuit, DLQ + revizuire manuală.
Observabilitate: SLO, alerte prin semnătură/latență/DLQ/lag.
Politica PII/anonimizare, audit ABAC, WORM.
DR/multi-regiune, repetiții feilover.
Runbooks: incidente, reluare, schema/rollback cheie.

15) Mini Case (sintetic)

Context: vârf de turneu, 120 la intrare RPS, 64 jocuri, 2 regiuni Active-Active.

Total pentru 4 săptămâni: ingera p95 210 ms, e2e p95 1. 6 s; DLQ 0. 05%; semnături de eroare 0. 009%; duplicate după idempotență 0. 003%.

Incident: deriva ceasului partenerului (− 9 min) → val anti-reluare. Întrerupătorul de circuit a transferat fluxul la punctul final „tampon”, CSM notificat partener-sănătate; după vânătaia NTP - fereastra rejucă 12 min tuturor consumatorilor. Nu există pierderi și plăți duble.

16) Rezumat

Un feed fiabil în timp real nu este "doar cârlige web. "Acesta este un sistem stratificat cu contracte clare: cel puțin o dată transport + logic exact-o dată, schema de înregistrare și versioning, MTLS/HMAC/JWT și rotație cheie, backpressure/DLQ/reluare, PII minimizare și audit strict. Urmând aceste practici, veți obține un flux rapid, sigur și previzibil de evenimente pe care puteți construi cu încredere gamificare, anti-fraudă, CRM și plăți.