Realtime-Feed von Veranstaltungen: Architektur und Sicherheit

Real-time Event-Feed ist das „Kreislaufsystem“ von Produkten mit Gamification, Antifrod, CRM-Triggern und Auszahlungen. Damit es bei Spitzen vorhersehbar funktioniert, keine Belohnungen dupliziert und keine Daten fließen, braucht es eine strenge Architektur: von Protokollen und Bus über Signatur, Idempotenz, Budgetkapper bis hin zur Beobachtbarkeit.

1) Ziele und Anforderungen

Zuverlässigkeit: Lieferung von Ereignissen mit minimaler Verzögerung (p95 ≤ 250 ms ingest, p95 ≤ 1-2 s bis zum Verbraucher).

Lieferung: at-least-once Transport + logische exactly-once durch Idempotenz.

Reihenfolge: Sortierung nach Schlüssel (meist 'user _ id') mit Umsortierfenstern.

Sicherheit: MTLS, HMAC/JWT, Schlüsselrotation, Replay/Duplikat-Schutz, PII-Minimierung.

Maßstab: Horizontale Sharding, Backpressure, Rate Limiting, DLQ/Replay.

Verwaltbarkeit: Schema-Registrierung, Versionierung, Migrationen ohne Ausfallzeiten.

Compliance: Audit (WORM), RG/KYC Gates, Geo-Policies, DSGVO/Anonymisierung.

2) Referenzarchitektur (Schicht für Schicht)

1. Produzenten (Quellen): Gaming-Server, Wallet/Payment, KYC/AML, Client-SDKs (Web/iOS/Android).

2. Gateway-API (Ingress): HTTP/gRPC-Empfang, Schemavalidierung, Authentifizierung, HMAC/MTLS, Zeitnormalisierung.

3. Queue/Stream: Kafka/Rabbit/Cloud Pub/Sub - Pufferung, Partitionierung nach 'user _ id'.

4. Stream-Prozessor: Normalisator, Anreicherung, Themen-Routing, Anormalitäts-/Antibot-Flags, idempotente Aufzeichnung.

5. Verbraucher: Regeln/Scoring, Reward Orchestrator, CRM/CDP-Konnektoren, Anti-Fraud, analytische Sink'i

6. Lagerung: Rohveranstaltungen (immutable), Schaufenster, Index für Idempotenz, Audit-Log.

7. Observability: Metriken, Logs, Traces, Alerts; panics → DLQ.

8. Admin Plane: schema registry, keys/secrets, RBAC/ABAC, ficheflags, replay-service.

3) Lieferprotokolle: wann was zu verwenden ist

HTTP/JSON (Server-to-Server-Webhooks): einfach, kompatibel, gut für externe Partner. HMAC + Idempotenz hinzufügen.

gRPC/Protobuf: geringe Latenz, strenge Schemata, Bidi-Streams für interne Dienste.

WebSocket/SSE: Push zum Client, UI-Abonnements für Leaderboards und Fortschritt.

CDC/Kafka Connect: Wenn die Quellen DBs/Wallets und keine Business-Services sind.

Empfehlung: Außenumfang - HTTP + HMAC + MTLS; innen - gRPC/Protobuf.

4) Veranstaltungs- und Konventionsmodell

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

Regeln:

Zwei Zeiten: 'occurred _ at' (Quelle) und 'ingested _ at' (Gateway). Lassen Sie die Uhr ± 300 s driften.
Der Routing-Schlüssel definiert die Reihenfolge (normalerweise' user _ id').
PII nur in „ctx “/„ payload“ nach dem Minimierungsprinzip; für sensible Attribute - Tokenisierung.

5) Lieferung, Ordnung und Idempotenz

At-least-once Transport → Duplikate und Neubestellungen sind möglich.

Exactly-once Logik: Halten Sie die Idempotenztabelle mit einem eindeutigen Index für'(event_id) 'und/oder' (user_id, source_seq)'; Wiederholung - no-op.

SQL-Sketch:

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

-- doppelsichere Einlage
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;

Reihenfolge: Partitionierung des Threads durch 'user _ id' + reordering window 60-120 s im Prozessor. Später eintretende Ereignisse fallen in ein „Replay“ (Replay) von Korrekturfunktionen.

6) Backpressure und Peak-Management

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

Circuit Breaker: Bei 5xx von inländischen Verbrauchern → die Degradation (Dropout von optionalen Ereignissen, Warteschlangen erhöhen die Retrayintervalle).

DLQ: permanent fehlerhafte Nachrichten (gebrochene Schaltung, Signatur ungültig, Signaturüberschreitung TTL).

Replay Service: Selektive Repablish von DLQ nach 'event _ id '/Zeitbereich.

7) Schemata und Evolution: wie man Prod nicht „bricht“

Schema Registry: JSON Schema/Protobuf; Kompatibilitätsrichtlinien: Backward für Produzenten, Forward für Consumer.

Versionierung: 'schema _ version', Dur - nur über Ficheflag und Double Write (Dual-Write).

Verträge: Förderung der Regelung nach der Kanarienperiode und grüne Metriken.

YAML-Beispielprüfregel:

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

8) Bedrohungsmodell und Schutz

Bedrohungen: Körperwechsel, Wiederholung (Replay), PII-Leck, Schlüsselkompromittierung, Schema-Poisoning, DoS, MITM, Signatur-Stripping.

Schutz:

MTLS am Perimeter: Kundenzertifikate mit kurzer Laufzeit, CRL/OCSP.
HMAC-Signatur des Körpers + „X-Timestamp“ und TTL (± 300 s).
JWT (Client credentials/OAuth2) - für die Autorisierung und Einschränkungen von Scope.
Schlüsselrotation (KMS): 'kid' im Header; Rotationsplan 30-90 Tage; Doppelprüfung im Migrationsfenster.
Nonce/Idempotence: „X-Request-Id“ für Nebenabfragen (Auszahlungen, Boni); Bewahren Sie die TTL für eine Weile auf.
Content-Type pinning, max body size, allow-list IP/ASN für kritische Integrationen.
WORM-Audit aller eingehenden raw-payload + Header (unveränderlicher Speicher).

Beispiel für eine HMAC-Prüfung (Pseudocode):

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) Privatsphäre, PII und RG/KYC

Minimierung: PII-Transfer per Link-Token (für 5-15 Minuten) anstelle von Inline; Bearbeitung/Anonymisierung in rohen Protokollen ist verboten - verwenden Sie separate PII-Storaner.

Zugang: ABAC nach Zuständigkeits- und Rollenattributen; Alle Lesungen sind im Audit-Journal.

DSGVO: Recht auf Löschung durch Key-Mapping umsetzen, um PII zu löschen, ohne den Sachverhalt der Ereignisse zu brechen.

RG/KYC: Ereignisse, die die Ausgabe wertvoller Auszeichnungen erfordern, nur mit gültigem KYC-Level und RG-Flags „OK“ überspringen.

10) Beobachtbarkeit und SLO

SLO (Beispiel):

Ingest p95 ≤ 250 ms end-to-end p95 ≤ 2 с; Ablehnung ≤ 0. 1 %/Tag.
Signaturfehler (HMAC/JWT) ≤ 0 02% des Gesamtstroms.
DLQ fill rate ≤ 0. 1%; „Duplikate“ nach Idempotenz ≤ 0 005%.

Dashboard:

RPS nach Quelle, p50/p95 Latenz, 4xx/5xx, Signaturen-Fehler, Zeit-Skew.
Lag nach Partitionen, Recycling/sec, DLQ-Fill, Retries, Replay-Volumes.
Schemata: Anteil der Nachrichten nach Version, Kompatibilitätsverletzungen.
Sicherheit: rps-throttle Frequenz, Circuit-Breakers, IP/ASN Anomalien.

Alerts (Beispiele):

Stream SRM (starke Verzerrung des Datenverkehrs aus einer Hand).
Latenz p95> Ziel 5 min +, DLQ-Wachstum> X/min.
Signaturfehler> Y ppm, Anstieg der Wiederholungen 'X-Request-Id'.
Drift Stunden> 120 s an der Quelle.

11) Multi-Region und Fehlertoleranz

Active-Active-Regionen, Global Routing (GeoDNS/Anycast), Sticky-Key durch 'user _ id' → Region.

Regionenübergreifender Replikationstopf für kritische Ereignisse (monetär, KYC).

Blast radius: Isolation nach Tenanten/Marken, separate Budgets und Schlüssel.

DR-Plan: RPO ≤ 5 min, RTO ≤ 30 min; Regelmäßige Proben.

12) Retenche und Replay-Politik

Rohveranstaltungen: 7-30 Tage (nach Wert), Einheiten/Schaufenster - länger.

Replikationen sind nur mit einem signierten Runbook (wer, was, warum, Zeitbereich) erlaubt.

Ein Replay geht immer in eine neue Stream-Version mit dem Flag 'replayed = true' für analytische Transparenz.

13) Beispiele für Konfigurationen

Ingress (NGINX-Stil) Grenzen:

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

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

Richtlinien für Schlüssel (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) Checkliste für den Start des Echtzeit-Feeds

MTLS am Perimeter, HMAC/JWT, Schlüsselrotation ("kid').
Idempotenz auf Logik (eindeutige Schlüssel, upsert/ON CONFLICT).
Partitionierung durch 'user _ id', Reordering-Fenster, Replay-Service.
Schema registry + Kompatibilitätsrichtlinien; Dual-Write bei Major-Updates.
Rate limiting, circuit breakers, DLQ + hand revue.
Beobachtbarkeit: SLO, signature/latence alerts/DLQ/lag.
PII/Anonymisierungsrichtlinie, ABAC, WORM-Audit.
DR/Multi-Region, Failover-Proben.
Runbooks: Incidents, Replays, Schemas/Keys Rollback.

15) Mini-Fall (synthetisch)

Kontext: Spitzenturniere, 120 to RPS ingress, 64 Parties, 2 Aktiv-Aktiv-Regionen.

Insgesamt 4 Wochen: ingest p95 210 ms, e2e p95 1. 6 s; DLQ 0. 05%; Signaturfehler 0. 009%; Duplikate nach Idempotenz 0. 003%.

Der Vorfall: Zeitdrift bei einem Partner (− 9 min) → ein Anstieg der Anti-Replay. Circuit Breaker hat den Stream in einen „Puffer“ -Endpunkt überführt, Partner-Health hat CSM benachrichtigt; nach NTP Synk - 12 min Fenster Replikate an alle Verbraucher. Verluste und Doppelzahlungen gibt es nicht.

16) Zusammenfassung

Ein zuverlässiger Echtzeit-Feed ist nicht „nur Webhooks“. Es ist ein Schichtsystem mit klaren Verträgen: at-least-once Transport + logische exactly-once, Schema-Register und Versionierung, MTLS/HMAC/JWT und Schlüsselrotation, Backpress/DLQ/Replikationen, PII-Minimierung und rigoroses Audit. Wenn Sie diese Praktiken befolgen, erhalten Sie einen schnellen, sicheren und vorhersehbaren Ereignisfluss, auf dem Sie sicher Gamification, Fraud, CRM und Auszahlungen aufbauen können.