Realtame-Fid d'événements : Architecture et sécurité

Le fid des événements est un « système circulatoire » de produits avec gamification, antifrood, déclencheurs CRM et paiements. Pour qu'il fonctionne de manière prévisible pendant les pics, qu'il ne double pas les récompenses et qu'il ne passe pas par les données, il faut une architecture rigoureuse, des protocoles et des pneus à la signature, à l'idempotence, au budget et à l'observation.

1) Objectifs et exigences

Fiabilité : livraison d'événements avec un minimum de retard (p95 ≤ 250 ms ingest, p95 ≤ 1-2 s jusqu'au consommateur).

Livraison : transport at-least-once + exactly-once logique par idempotence.

Ordre : Ordonnancement par clé (généralement "user _ id') avec des fenêtres de réorganisation.

Sécurité : MTLS, HMAC/JWT, rotation des clés, protection contre le replay/duplicata, minimisation des PII.

Échelle : sharding horizontal, backpressure, rate limiting, DLQ/repliement.

Gestion : schema registry, versioning, migration sans interruption de service.

Conformité : audit (WORM), gates RG/KYC, geo-politiques, RGPD/anonymisation.

2) Architecture de support (couche par couche)

1. Producteurs (sources) : serveur de jeu, portefeuille/paiement, KYC/AML, SDK client (web/iOS/Android).

2. API Gateway (Ingress) : réception HTTP/gRPC, validation de schéma, authentification, HMAC/MTLS, normalisation du temps.

3. Queue/Stream : Kafka/Rabbit/Cloud Pub/Sub est un tampon, un lot par 'user _ id'.

4. Processeur Stream : normalisateur, enrichissement, acheminement des thèmes, drapeaux anormalia/antibot, enregistrement idempotent.

5. Consommateurs : Rules/Scoring, Reward Orchestrator, CRM/CDP connecteurs, antifrod, analytique sink'et

6. Storage : événements bruts (immutables), vitrines, indice d'idempotence, audit-journal.

7. Observability : métriques, logs, tracés, alertes ; panics → DLQ.

8. Admin Plane : schema registry, clés/secrets, RBAC/ABAC, ficheflags, service de relais.

3) Protocoles de livraison : quand quoi utiliser

HTTP/JSON (server-to-server webhooks) : simple, compatible, bon pour les partenaires externes. Ajouter HMAC + idempotence.

gRPC/Protobuf : faible latence, schémas rigoureux, bidi-streams pour les services internes.

WebSocket/SSE : push to customer, UI-abonnements aux leaders et progrès.

CDC/Kafka Connect : quand les sources sont des bases de données/portefeuilles, pas des services aux entreprises.

Recommandation : périmètre externe - HTTP + HMAC + MTLS ; à l'intérieur - gRPC/Protobuf.

4) Le modèle de l'événement et de la convention

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

Règles :

Deux temps : 'occurred _ at' (source) et 'ingested _ at' (passerelle). Admettez la dérive de l'horloge ± 300 s.
La clé de routage est ce qui définit l'ordre (généralement "user _ id').
PII uniquement en 'ctx '/' payload' selon le principe de minimisation ; pour les attributs sensibles, la tokenisation.

5) Livraison, ordre et idempotence

Le transport at-least-once → peut être dupliqué et réorganisé.

Logique exactly-once : garder la table d'idempotence avec un indice unique par '(event_id)' et/ou '(user_id, source_seq)' ; la répétition est no-op.

Sketch SQL :

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

- insert avec protection contre les prises
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;

Ordre : Lot du flux par 'user _ id' + reordering window 60-120 s dans le processeur. Plus tard, les événements qui arrivent tombent dans le « replay » (replay) des fonctions de correction.

6) Backpressure et gestion des pics

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

Circuit breaker : à 5xx des consommateurs internes, la dégradation est → (dropout des événements facultatifs, les files d'attente augmentent les intervalles rétroactifs).

DLQ : Messages perpétuellement erronés (circuit de bits, signature non validée, dépassée par la TTL de signature).

Service Replay : Repablish sélectif de DLQ par 'event _ id'/plage temporelle.

7) Schémas et évolution : comment ne pas « casser » la prod

Schema Registry: JSON Schema/Protobuf; politiques de compatibilité : backward pour les producteurs, forward pour les consumers.

Versioning : 'schema _ version', majeur - uniquement via ficheflag et double enregistrement (dual-write).

Contrats : promotion du dispositif après la période canarienne et metrics verts.

YAML exemple de règle de vérification :

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

8) Modèle de menace et protection

Menaces : échange de corps, répétition (replay), fuite PII, compromission de clé, schema-poisoning, DoS, MITM, signature-stripping.

Protection :

MTLS sur le périmètre : certificats clients à court terme, CRL/OCSP.
Signature HMAC du corps + « X-Timestamp » et TTL (± 300 s).
JWT (client credentials/OAuth2) - pour l'autorisation et les restrictions de scope.
Rotation de clés (KMS) : 'kid' dans l'en-tête ; un plan de rotation de 30 à 90 jours ; double vérification dans la fenêtre de migration.
Nonce/idempotence : 'X-Request-Id' pour les demandes d'aide (paiements, bonus) ; Stockez le TTL pendant un certain temps.
Content-Type pinning, max body size, allow-list IP/ASN pour les intégrations critiques.
Audit WORM de tous les titres raw-payload + entrants (stockage immuable).

Exemple de vérification HMAC (pseudo-code) :

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) Vie privée, PII et RG/KYC

Minimisation : Transmettre le PII en utilisant le token de référence (de 5 à 15 minutes) au lieu de l'inline ; L'édition/anonymisation dans les logs bruts est interdite - utilisez des stores PII distincts.

Accès : ABAC selon les attributs de compétence et de rôle ; toutes les lectures sont dans le journal d'audit.

RGPD : exercer le droit de suppression via key-mapping pour effacer PII sans casser les faits des événements.

RG/KYC : Les événements qui nécessitent des récompenses précieuses ne sont manquants que lorsque le niveau KYC et les drapeaux RG « OK » sont valides.

10) Observabilité et SLO

SLO (exemple) :

Ingest p95 ≤ 250 ms ; end-to-end p95 ≤ 2 с; refus ≤ 0. 1 %/24 heures.
Signature-erreur (HMAC/JWT) ≤ 0. 02 % du flux total.
DLQ fill rate ≤ 0. 1%; « doublons » après idempotence ≤ 0. 005%.

Dushbord :

RPS par source, p50/p95 latency, 4xx/5xx, signature-erreur, time-skew.
Lag par lots, recyclage/s, fill DLQ, retries, rebonds.
Schémas : proportion de messages par version, violations de la compatibilité.
Sécurité : fréquence rps-throttle, circuits-breakers, anomalies IP/ASN.

Alert (exemples) :

Flux SRM (forte distorsion du trafic d'une seule source).
Latence p95> cible 5 min +, croissance DLQ> X/min.
Légendes-erreurs> Y ppm, sursaut de répétition 'X-Request-Id'.
Montre Drift> 120 s à la source.

11) Multi-région et tolérance aux pannes

Régions Active-Active, itinérance mondiale (GeoDNS/Anycast), sticky-key par 'user _ id' → région.

Point de réplication intersectoriel pour les événements critiques (argent, KYC).

Blast radius : isolation par tenants/marques, budgets individuels et clés.

Plan DR : RPO ≤ 5 min, RTO ≤ 30 min ; des répétitions régulières.

12) Politiques de rétention et de repli

Événements crus : 7-30 jours (en valeur), agrégats/vitrines - plus longtemps.

Le replay n'est autorisé que par le runbook signé (qui, quoi, pourquoi, la plage de temps).

Le replay va toujours dans la nouvelle version stream avec l'indicateur 'replayed = true' pour la transparence analytique.

13) Exemples de configurations

Ingress (style NGINX) limites :

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 (exemple) :

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

Politique pour les clés (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) Chèque de lancement du fid real-time

MTLS sur le périmètre, HMAC/JWT, rotation des clés ('kid').
Idempotence sur la logique (clés uniques, upsert/ON CONFLICT).
Lot par 'user _ id', reordering window, service de repli.
Schema registry + politiques d'interopérabilité ; dual-write dans les updates majeurs.
Rate limiting, circuit breakers, DLQ + rhubarbe manuelle.
Observabilité : SLO, alertes par signature/latence/DLQ/lag.
Politique PII/anonymisation, ABAC, audit WORM.
DR/multi-région, répétitions de faussaires.
Runbooks : incidents, repli, retour des schémas/clés.

15) Mini case (synthétique)

Contexte : pic des tournois, 120 à RPS ingress, 64 parties, 2 régions Active-Active.

Total en 4 semaines : ingest p95 210 ms, e2e p95 1. 6 s ; DLQ 0. 05%; signature-erreur 0. 009%; doublons après idempotence 0. 003%.

L'incident : la dérive de l'horloge chez le partenaire (− 9 min) → une poussée anti-replay. Circuit breaker a transféré le flux dans l'endpoint « tampon », le partenaire-santé a alerté le CSM ; après le synk NTP - braquer la fenêtre 12 min à tous les consomers. Il n'y a pas de pertes et de doubles paiements.

16) Résumé

Un fid de temps réel fiable n'est pas « juste un webhooke ». C'est un système stratifié avec des contrats clairs : transport at-least-once + logique exactly-once, schéma-registre et versioning, MTLS/HMAC/JWT et rotation des clés, backpressure/DLQ/repli, minimisation PII et audit strict. En respectant ces pratiques, vous obtiendrez un flux d'événements rapide, sûr et prévisible sur lequel vous pouvez construire en toute confiance la gamification, l'antifrod, le CRM et les paiements.