Evento de realtaim: arquitetura e segurança

O feed real-time de eventos é um «sistema sanguíneo» de produtos com gamificação, antifrode, desencadeadores CRM e pagamentos. Para que ele funcione previsivelmente em picos, sem duplicar prêmios e sem fluir dados, é preciso ter uma arquitetura rigorosa, desde protocolos e pneus até assinatura, idempotação, orçamento-caper e observabilidade.

1) Objetivos e requisitos

Confiabilidade: entrega de eventos com laje mínima (p95 ≤ 250 ms ingest, p95 ≤ 1-2 c para o consumidor).

Transporte at-least-once + exactly-once lógico através da idempotação.

Ordem: Ordem por chave (normalmente 'user _ id') com janelas de reordenamento.

Segurança: MTLS, HMAC/JWT, rotação de chaves, proteção contra replay/duplicados, minimização de PII.

Escala: sharding horizontal, backpressure, rate limiting, DLQ/réplica.

Governabilidade: schema registry, versionização, migração sem interrupção.

Auditoria (WORM), gates RG/KYC, geo-política, GDPR/Anonimização.

2) Arquitetura de apoio (camada após camada)

1. Produtos (fontes): servidor de jogos, carteira/pagamento, KYC/AML, SDK cliente (web/iOS/Android).

2. API Gateway (Ingress): recepção de HTTP/gRPC, validação de esquema, autenticação, HMAC/MTLS, normalização do tempo.

3. Queue/Stream: Kafka/Rabbit/Cloud Pub/Sub - Tampão, partilha por 'user _ id'.

4. Stream Processor: Normalizador, Enriquecimento, Rotação de tópicos, Anormália/Bandeiras Anti, Gravação Idempotental.

5. Consumers: Rulas/Scoring, Reward Orquestrador, CRM/CDP conectores, antifrode, sink 's.

6. Armazenamento: eventos crus (imutable), vitrines, índice de idempotação, registo de auditoria.

7. Observabilidade: métricas, logs, traçados, alertas; panics → DLQ.

8. Admin Plane: schema registry, chaves/segredos, RBAC/ABAC, ficheflags, serviço de replay.

3) Protocolos de entrega: quando usar

HTTP/JSON (server-to-server webhooks): Simples, compatível, bom para parceiros externos. Adicionar HMAC + idempotidade.

gRPC/Protobuf: atraso baixo, esquema rigoroso, bidi striam para serviços internos.

WebSocket/SSE: push para cliente, assinaturas UI para liderbords e progresso.

CDC/Kafka Connect: quando as fontes são BD/carteira, não serviços de negócios.

Recomendação: perímetro externo - HTTP + HMAC + MTLS; lá dentro, gRPC/Protobuf.

4) Modelo de evento e convenções

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

Regras:

Dois tempos: 'occurred _ at' (origem) e 'ingested _ at' (gateway). Aceitem a deriva do relógio de £300 s.
A chave de roteiro é o que determina a ordem (normalmente 'user _ id').
PII apenas em 'ctx '/' payload' sob o princípio de minimização; para atributos sensíveis - toquenização.

5) Entrega, ordem e idepotência

Transporte at-least-once → pode ser duplicado e reordenado.

Exactly-once lógica: mantenha a tabela de idempotação com índice único por '(event _ id)' e/ou '(user _ id, fonte _ seq)'; a repetição é 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
);

-- inserção com proteção contra suplementos
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;

Ordem: Particionamento do fluxo em 'user _ id' + reordering window 60-120 s no processador. Mais tarde, os eventos ocorridos entram em «reencontro» (replay) das funções de correção.

6) Backpressure e controle de picos

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

Circuito breaker: a 5xx dos consumidores internos → degradação (drapaute de eventos opcionais, filas aumentam os intervalos de retração).

DLQ: mensagens permanentemente erradas (esquema batido, assinatura não assinada, assinaturas TTL ultrapassadas).

Serviço Replay: Repablish seletivo de DLQ por 'event _ id '/intervalo de tempo.

7) Esquemas e evolução: como não «quebrar» a proda

Schema Registry: JSON Schema/Protobuf; políticas de compatibilidade: backward para produtores, forward para consórcios.

Versioning: 'schema _ version', maior - somente através de fichiflag e dupla gravação (dual-write).

Contratos: promoção do esquema pós-canário e green metrics.

Um exemplo YAML da regra de verificação:

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

8) Modelo de ameaças e proteção

Ameaças: troca de corpo, repetição (replay), fuga de PII, comprometimento da chave, schema-poisoning, DoS, MITM, assinatura-stripping.

Proteção:

MTLS no perímetro: certificados de cliente de curta duração, CRL/OCSP.
A assinatura HMAC do corpo + 'X-Timestamp' e TTL (300 c).
JWT (cliente credentals/OAuth2) - para permissão e restrições de scope.
Rotação de chaves (KMS): 'kid' no cabeçalho; plano de rotação de 30 a 90 dias; verificação dupla na janela de migração.
«X-Request-Id» para solicitações-subsolo (pagamentos, bônus); guarde por tempo de TTL.
Contém-Tipo pinning, max body size, allow-list IP/ASN para integrações críticas.
Auditoria WORM de todas as entradas de raw-payload + cabeçalhos (armazenamento inalterável).

Exemplo de teste HMAC (pseudo-código):

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) Privacidade, PII e RG/KYC

Minimização: PII transmitido por link-token (de 5 a 15 minutos) em vez de inline; edição/anonimato em logs crus são proibidos - use estacionadores PII individuais.

Acesso: ABAC por atributos de jurisdição e papel; todas as leituras estão no registo de auditoria.

GDPR: Execute o direito de remoção através do key-maping para apagar o PII sem quebrar os eventos.

RG/KYC: Os eventos que exigem prémios valiosos só faltam quando o nível KYC e as bandeiras RG forem validadas.

10) Observabilidade e SLO

SLO (exemplo):

Ingest p95 ≤ 250 ms; end-to-end p95 ≤ 2 с; recusa ≤ 0. 1 %/dia.
Assinatura de erro (HMAC/JWT) ≤ 0. 02% do fluxo total.
DLQ fill rate ≤ 0. 1%; «duplicados» após idempotação ≤ 0. 005%.

Dashboard:

RPS de origem, p50/p95 latency, 4xx/5xx, assinaturas-erro, time-skew.
Lag por partituras, reciclagem/segundo, fill DLQ, retrias, réplicas-volume.
Esquemas: proporção de mensagens por versão, violações de compatibilidade.
Segurança: rps-throttle, circuito-breakers, anomalias IP/ASN.

Alerts (exemplos):

O fluxo SRM (distorção acentuada do tráfego de uma única fonte).
Latidão p95> alvo 5 min +, crescimento DLQ> X/min.
Assinaturas de erro> Y ppm, ressalvas de repetição 'X-Request-Id'.
Draft relógio> 120 com a origem.

11) Região multi e resistência a falhas

Regiões Ativas, routing global (GeoDNS/Anycast), sticky-key por 'user _ id' → região.

Top de replicação cruzada regional para eventos críticos (dinheiro, KYC).

Blast radius: isolamento por tenentes/marcas, orçamentos e chaves individuais.

Plano DR.: RPO ≤ 5 min, RTO ≤ 30 min; ensaios regulares.

12) Políticas de retenha e réplica

Eventos crus: 7 a 30 dias (a custo), equipamentos/vitrines por mais tempo.

As réplicas são permitidas apenas pelo runbook assinado (quem, porquê, faixa de tempo).

As réplicas vão sempre para uma nova versão stream com a bandeira 'replayed = true' para transparência analítica.

13) Exemplos de configuração

Origins (estilo 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 (exemplo):

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

Policy para chaves (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) Folha de cheque de lançamento real-time de fide

MTLS no perímetro, HMAC/JWT, rotação de chaves ('kid').
Idempotidade na lógica (chaves únicas, upsert/ON CONFLICT).
Particionamento por 'user _ id', reordering window, serviço de réplica.
Schema registry + políticas de compatibilidade; dual-write para maiores-updates.
Rate limiting, circuito breakers, DLQ + revezamento manual.
Observabilidade: SLO, alertas por assinatura/latência/DLQ/lag.
Política PII/Anonimização, ABAC, Auditoria WORM.
Dr./multi-região, ensaios do feelover.
Runbooks: incidentes, réplicas, reversão de circuitos/chaves.

15) Mini-mala (sintético)

Contexto: picos de torneios, 120 para RPS ingress, 64 partições, 2 regiões do Ativo.

Total de 4 semanas: ingest p95 210 ms, e2e p95 1. 6 c; DLQ 0. 05%; assinaturas de erro 0. 009%; Duplicado após idempotação 0. 003%.

Incidente: A deriva do relógio do parceiro (- 9 min) → uma subida anti-replay. O circuito breaker transferiu o fluxo para um endpoint «tampão», o parceiro-health alertou o CSM; após o sink NTP - réplicas da janela de 12 min para todos os consoadores. Não há perdas ou pagamentos duplos.

16) Resumos

Um fid real-time seguro não é apenas «webhooks». Este é um sistema de camadas com contratos nítidos: transporte at-least-once + excactly-once lógico, registros de circuito e versionagem, MTLS/HMAC/JWT e rotação de chaves, backpressure/DLQ/réplica, minimização de PII e auditoria rigorosa. Seguindo essas práticas, você vai obter um fluxo rápido, seguro e previsível de eventos, no qual você pode construir com segurança gamificagem, antifrode, CRM e pagamentos.