Realtime Feed Wydarzenia: Architektura i bezpieczeństwo

Kanał zdarzeń w czasie rzeczywistym jest „systemem krążenia” produktów z gier, zwalczania oszustw, wyzwalaczy CRM i płatności. Aby działać przewidywalnie na szczytach, nie duplikować nagród i nie wyciekać danych, potrzebna jest ścisła architektura: od protokołów i autobusów po podpis, idempotencję, prywatników budżetowych i obserwowalność.

1) Cele i wymagania

Niezawodność: dostawa zdarzeń o minimalnym opóźnieniu (p95 ≤ 250 ms połknięcia, p95 ≤ 1-2 s do konsumenta).

Dostawa: co najmniej raz transport + logiczny dokładnie raz przez idempotencję.

Zamawianie: zamawianie za pomocą klucza (zwykle 'user _ id') z kolejnością okien.

Bezpieczeństwo: MTLS, HMAC/JWT, obrót klucza, powtórka/duplikat ochrony, minimalizacja PII.

Skala: poziomy odcień, ciśnienie wsteczne, ograniczenie prędkości, DLQ/powtórka.

Możliwość zarządzania: rejestr schematu, wersioning, migracje bez przestojów.

Zgodność: audyt (WORM), bramy RG/KYC, geopolityka, RODO/anonimizacja.

2) Architektura odniesienia (warstwa po warstwie)

1. Producenci (źródła): serwer gier, portfel/płatność, KYC/AML, SDK klienta (web/iOS/Android).

2. Brama API (Ingress): odbiór HTTP/gRPC, walidacja schematu, uwierzytelnianie, HMAC/MTLS, normalizacja czasu.

3. Kolejka/strumień: Kafka/Królik/Cloud Pub/Sub - buforowanie, partycjonowanie przez 'user _ id'.

4. Procesor strumieniowy: normalizator, wzbogacanie, routing tematyczny, flagi anomalii/anty-botów, nagrywanie idempotentne.

5. Konsumenci: Zasady/Punktacja, Reward Orchestrator, złącza CRM/CDP, anty-oszustwa, zlewozmywak analityczny'i.

6. Przechowywanie: niezmienne zdarzenia, sklepy, indeks dla idempotencji, dziennik audytu.

7. Obserwowalność: mierniki, kłody, ślady, wpisy; panika → DLQ.

8. Admin Plane: rejestr schematu, klucze/sekrety, RBAC/ABAC, phicheflags, usługa replay.

3) Protokoły dostawy: kiedy użyć co

HTTP/JSON (server-to-server webhooks): proste, kompatybilne, dobre dla zewnętrznych partnerów. Dodaj HMAC + idempotencję.

gRPC/Protobuf: niskie opóźnienia, ścisłe schematy, strumienie bidi dla usług wewnętrznych.

WebSocket/SSE: push do klienta, subskrypcje interfejsu do liderów i postęp.

CDC/Kafka Connect: kiedy źródła są bazami danych/portfelami, a nie usługami biznesowymi.

Zalecenie: obwód zewnętrzny - HTTP + HMAC + MTLS; wewnątrz - gRPC/Protobuf.

4) Model wydarzeń i konwencji

json
{
„event_id": „e_01HF3Z8Z7Q8Q2K,” „event_type": „zakład”, „schema_version": „1. 3. 0”, „occurred_at": „2025-10-24T11:37:21Z,” „ingested_at": „2025-10-24T11:37:21. 183Z,” „klucz”: {„user_id": „u_12345”}, „ctx”: {
„session_id": „s_778,” „platforma”: „ios”, „geo”: „TR”, „device_fp": „fp_4a1...”
}, „ładunek użytkowy”: {
"game_id": "slot_wolf," "zakład": 0. 5, "wygraj': 1. 25, „waluta”: „EUR”, „dostawca”: „GameCo”
}, „sig”: {
"algo": "HMAC-SHA256," "dziecko": "k_2025_10," "ts': 1730061441," mac ":" c7b7b3... f1 "
}
}

Zasady:

Dwa razy są 'occurred _ at' (źródło) i 'ingested _ at' (gateway). Pozostawić zegar do dryfowania ± 300 s.
Klucz routingu jest tym, co określa kolejność (zwykle 'user _ id').
PII tylko w „ctx ”/„ ładunek użytkowy” na zasadzie minimalizacji; dla atrybutów wrażliwych, tokenizacja.

5) Dostawa, zamówienie i idempotencja

Co najmniej raz transport → duplikaty i ponowne zamawianie są możliwe.

Logika dokładnie raz: przechowywać tabelę idempotencji z niepowtarzalnym indeksem na '(event_id)' lub '(user_id, source_seq)'; powtarzam - no-op.

Szkic SQL:

sql
UTWÓRZ TABELĘ event_log (
event_id KLUCZ PODSTAWOWY TEKSTU, TEKST user_id, TEKST event_type, occurred_at TIMESTAMPTZ, ładunek użytkowy JSONB
);

-- podwójnie zabezpieczona wkładka
WSTAWIĆ DO event_log (event_id, user_id, event_type, occurred_at, ładunek użytkowy)
WARTOŚCI (:event_id,:user_id,:event_type,:occurred_at,:payload)
w sprawie konfliktu (event_id) nie robić nic;

Zamówienie: partycjonowanie strumienia przez 'user _ id' + ponowne zamówienie okna 60-120 sekund w procesorze. Później zdarzenia, które pojawiają się wpadają w „powtórkę” funkcji korekcyjnych.

6) Zarządzanie ciśnieniem wstecznym i szczytowym

Wskaźnik Token-bucket ograniczający на ingress (per-IP, per-partner, per-key).

Wyłącznik: z 5xx od wewnętrznych konsumentów, degradacja → (kropla opcjonalnych zdarzeń, kolejki zwiększają przedziały retrasy).

DLQ: wiadomości na stałe błędne (bitmap, podpis nieprawidłowy, podpis TTL przekroczony).

Usługa powtarzania: Selektywne powtórzenie DLQ przez 'event _ id'/zakres czasu.

7) Schematy i ewolucja: jak nie „złamać” prod

Rejestr schematu: JSON Schema/Protobuf; polityka kompatybilności: wstecz dla producentów, naprzód dla konsumentów.

Wersioning: 'schema _ version', major - tylko poprzez ficheflag i double-write (dual-write).

Kontrakty: promocja programu po okresie kanaryjskim i zielone metryki.

YAML example validation rule:

kompatybilność yaml:
enforce: true mode: backward blocked_fields:
- ładunek użytkowy. ssn
- ładunek użytkowy. card_number required_fields:
- event_id
- event_type
- occurred_at

8) Model zagrożenia i ochrona

Zagrożenia: spoofing ciała, powtórka, wyciek PII, kluczowy kompromis, zatrucie schematem, DoS, MITM, usuwanie podpisów.

Ochrona:

MTLS na obwodzie: krótkoterminowe certyfikaty klienta, CRL/OCSP.
Podpis nadwozia HMAC + „X-Timestamp” i TTL (± 300 s).
JWT (credentials/OAuth2 klienta) - dla ograniczeń autoryzacji i zakresu.
Rotacja klucza (KMS): „kid” w nagłówku; plan rotacji 30-90 dni; podwójne sprawdzenie w oknie migracji.
Nonce/idempotency: "X-Request-Id' dla wniosków ubocznych (płatności, premie); Zatrzymaj TTL przez jakiś czas.
Sworznie typu Content, maksymalny rozmiar nadwozia, lista IP/ASN dla integracji krytycznych.
Audyt WORM wszystkich przychodzących nagłówków raw-payload + (niezmienne przechowywanie).

Przykład badania HMAC (pseudo code):

python body = request. raw_body ts = int (żądanie. nagłówki [” X-Timestamp”])
assert abs (now () - ts) <= 300 # анта-replay kid = request. nagłówki ["X-Key-Id']
secret = km. pobierz (dziecko)
mac = hmac_sha256 (tajemnica, ciało)
assert hmac_eq (mac, request. nagłówki [” X-Signature”])

9) Prywatność, PII i RG/KYC

Minimalizacja: przenieść PII za pomocą łącza tokenowego (przez 5-15 minut) zamiast inline; edycja/anonimizacja w dziennikach surowych jest zabroniona - użyj oddzielnych stron PII.

Dostęp: ABAC według jurysdykcji i atrybutów roli; wszystkie odczyty - do dziennika audytu.

RODO: wykonywanie prawa do usunięcia poprzez mapowanie kluczy w celu usunięcia PII bez łamania faktów zdarzeń.

RG/KYC: Wydarzenia, które wymagają cennych nagród, pominąć tylko z ważnym poziomem KYC i flagami RG „OK”.

10) Obserwowalność i SLO

SLO (przykład):

Połknięcie p95 ≤ 250 ms; end-to-end p95 ≤ 2 α; awaria ≤ 0. 1 %/dzień.
Podpis błędu (HMAC/JWT) ≤ 0. 02% całkowitego przepływu.
Wskaźnik wypełnienia DLQ ≤ 0. 1%; „duplikaty” po idempotencji ≤ 0. 005%.

Deska rozdzielcza:

RPS według źródła, p50/p95 latency, 4xx/5xx, podpisy błędów, time-skew.
Lag po stronie, przetwarzanie/sec, wypełnianie DLQ, ponowne próby, powtarzanie woluminów.
Schematy: udział wiadomości według wersji, naruszenia zgodności.
Bezpieczeństwo: szybkość przepustnicy, wyłączniki, anomalie IP/ASN.

Wpisy (przykłady):

SRM przepływu (ostre zniekształcenie ruchu z jednego źródła).
Opóźnienie p95> cel 5 min +, wzrost DLQ> X/min.
Podpisy błędów> Y ppm, spike replay 'X-Request-Id'.
Godziny dryfu> 120 s u źródła.

11) Tolerancja wielobranżowa i błędna

Aktywne regiony, globalny routing (GeoDNS/Anycast), klucz sticky przez 'user _ id' → region.

Interregionalny temat replikacji dla wydarzeń krytycznych (pieniężnych, KYC).

Promień wybuchu: izolacja przez najemców/marek, poszczególne budżety i klucze.

DR-plan: RPO ≤ 5 min, RTO ≤ 30 min; regularne próby.

12) Polityka zatrzymywania i powtarzania

Wydarzenia surowe: 7-30 dni (według kosztów), kruszywa/prezentacje - dłuższe.

Powtórka jest dozwolona tylko przez podpisaną książkę startową (kto, co, dlaczego, zakres czasu).

Powtórka zawsze idzie do nowej wersji strumieniowej z flagą 'replayed = true' dla przejrzystości analitycznej.

13) Przykłady konfiguracji

Ingress (styl NGINX) limity:

nginx limit_req_zone $ binary _ remote _ addr zone = req _ limit: 10m rate = 300r/s;
strefa limit_req = req _ limit burst = 600 nodelay;

512k client_max_body_size;
proxy_read_timeout 5s;

Kafka (przykład):

właściwości nr przegrody = 64 min. insync. repliki = 2 acki = wszystkie zatrzymania. ms = 604800000 # 7 dni kompresji. typ = zstd

Polityka dla kluczy (KMS):

yaml rotation_days: 45 grace_period_days: 7 allow_algos: [„HMAC-SHA256”]
key_scopes:
- temat: „wallet_events”
producenci: ["portfel-svc']
konsumenci: [„ledger-svc',” risk-svc']

14) Lista kontrolna uruchomienia paszy w czasie rzeczywistym

MTLS na obwodzie, HMAC/JWT, rotacja klucza („dziecko”).
Idempotencja w logice (unikalne klucze, upsert/ON CONFLICT).
Partycjonowanie przez 'user _ id', ponowne zamawianie okna, usługa replay.
Schemat rejestru + polityki zgodności; dual-write dla głównych aktualizacji.
Ograniczenie prędkości, wyłączniki, DLQ + ręczny przegląd.
Obserwowalność: SLO, wpisy przez podpis/opóźnienie/DLQ/lag.
Polityka PII/anonimizacja, ABAC, audyt WORM.
DR/multi-region, próby feilover.
Książki startowe: incydenty, powtórka, schemat/key rollback.

15) Mini Case (syntetyczny)

Kontekst: szczyt turnieju, 120 do RPS ingress, 64 gry, 2 aktywne regiony.

Łącznie przez 4 tygodnie: połknięcie p95 210 ms, e2e p95 1. 6 s; DLQ 0. 05%; podpisy błędów 0. 009%; duplikaty po idempotencji 0. 003%.

Incydent: partner's zegar drift (− 9 min) → anty-replay surge. Wyłącznik przeniósł strumień do punktu końcowego „bufor”, partner-health powiadomiony CSM; po siniaku NTP - okno powtarza 12 min dla wszystkich konsumentów. Nie ma strat i podwójnych płatności.

16) Podsumowanie

Niezawodny kanał w czasie rzeczywistym nie jest "tylko haki internetowe. "Jest to system warstwowy z jasnymi umowami: co najmniej raz transport + logiczny dokładnie raz, system rejestrowania i wersioning, MTLS/HMAC/JWT i rotacja klucza, backpressure/DLQ/replay, minimalizacja PII i ścisły audyt. Postępując zgodnie z tymi praktykami, otrzymasz szybki, bezpieczny i przewidywalny strumień wydarzeń, na którym możesz ufnie budować gry, zwalczanie oszustw, CRM i płatności.