Strim e eventos
TL; DR
Estrim de trabalho = canal confiável (WSS) + offsets resumidos + eventos idumpotentes + limites rigorosos e backpressure. Faça: autenticação JWT, permissão para topics, heartbeats, seq/offset + resume-token, at-least-once + dedup. Para a escala - charding por user/tenant, sticky routing, e fila (Kafka/NATS/Redis Streams) como fonte de verdade.
1) Malas de negócios iGaming (o que é real)
Balanço/limite: alterações instantâneas no balanço, limites de RG, bloqueios.
Apostas/rodadas/resultados: confirmação, status, cálculo de ganhos.
Torneios/liderbords: posições, times, eventos de prémio.
Pagamentos: status de payout/refund, bandeiras KYC/AML - como notificações (e críticas permanecem no site REST +).
Eventos de serviço: mensagens de bate-papo, banners push, estatais de sessão, maintenance.
2) Protocolo e conexão
Apenas WSS (TLS 1. 2+/1. 3). No máximo 1 conexão ativa por dispositivo/sessão padrão.
Ping/Pong: O cliente envia 'ping' a cada 20-30 s, o tempo de resposta 10 c. O servidor reativa a conexão a 3 temporizações consecutivas.
Compressão: 'percessage-deflate', limite de tamanho de quadro (por exemplo, ≤ 64 KB).
Formato de carga útil: JSON para exterior, Protobuf/MsgPack para interior/celular.
3) Autenticação e autorização
Handschake com JWT em query/header ('Sec-WebSocket-Protocol '/' Autorization'), TTL token curto (≤ 15 min), refresh por out-of-band (REST).
Tenant-scoped claims: `sub`, `tenant`, `scopes`, `risk_flags`.
LCA para topics/canais: subscrição apenas para 'topic' permitidos (por exemplo: 'user: se é que você está a usar', 'tornment:', por exemplo, '...
Reencontrar a conexão quando o token passar: «janela macia» 60 s.
4) Modelo de assinaturas
O cliente envia comandos após o connect:json
{ "op":"subscribe", "topics":["user:123", "tournament:456"], "resume_from":"1748852201:987654" }
{ "op":"unsubscribe", "topics":["tournament:456"] }
'resume _ from' - Offset (consulte no parágrafo 5) se o cliente restabelecer a conexão.
O servidor responde ack/nack com LCA pendente em 'nack' s 'reason'.
5) Garantias de entrega e resumo
Objetivo: at-least-once por canal + idempotidade do cliente.
Cada evento tem um «seq» monótono dentro de uma «partição» (normalmente user/room) e um «event _ id» global para um dedupo.
No ré-connet, o cliente transmite 'resume _ from' = o último confirmado 'seq' (ou 'offset' do corretor). O servidor ignora eventos omitidos da «fonte da verdade» (Kafka/NATS/Redis Streams).
Se a liga exceder a retenção (por exemplo, 24 h), o servidor envia 'snapshot' estados e um novo 'seq'.
- Armazenar 'last _ seq '/' event _ id' em um armazenamento durable (IndexedDB/Keychain).
- Por 'event _ id', ignorar eventos com 'seq' last _ seq ', detectar buracos (gap) ' resync 'automático.
6) Padrão de mensagem (envelope)
json
{
"ts": "2025-11-03T12:34:56. 789Z",
"topic": "user:123",
"seq": "1748852201:987654", // partition:offset
"event_id": "01HF..", // UUID/KSUID
"type": "balance. updated",
"data": { "currency":"EUR", "delta"--5. 00, "balance":125. 37 },
"trace_id": "4e3f.., "//for correlation
"signature": "base64 (hmac (...)) "//optional for partners
}
'tipo' é uma taxonomia de domínio (consulte dicionário de eventos).
PII/PCI - Excluir/mascarar no nível da entrada.
7) Backpressure, quotas e proteção contra clientes «caros»
Server → Cliente: per-connation send-queue com «janela deslizante». Cheio - Redefinir assinaturas para topics «ruidosos» ou disconnect com o código «1013 »/« policy _ violation».
Cliente → Server: limites para 'subscribe/unsubscribe' (por exemplo, ≤ 10/segundo), restrição de lista de topics (≤ 50), intervalo mínimo de nova assinatura.
Rate limits por IP/tenant/chave. Anomalias → bloqueio temporário.
Priority: Eventos vitais (equilíbrio, limites RG) - fila prioritária.
8) Proteção e segurança
Perfil WAF/bot no handschake endpoint, lista de permissões Origin.
Entre a entrada edge e os nós estrim.
Proteção DoS: cookies SYN em L4, limites para o número de WS abertos/intervalo keep-alive.
Anti-replay: 'timestamp' na assinatura opcional de carga útil (para parceiros) com janela válida de 5 min.
Isolamento dos inquilinos: charding físico/lógico, chaves/tokens per-tenant.
9) Arquitetura de transporte
Gateway (edge): terminate TLS, authN/Z, quotas, rotação para partitura.
Stream-nódulos: stateless-worker com sticky-routing por 'hash (user _ id)% N'.
Corretor de eventos: Kafka/NATS/Redis Streams - fonte de verdade e replay-tampão.
Serviço State: armazena súplicas (balança, posições no torneio).
Multiregião: ativo-ativo; GSLB na região mais próxima; home-region é fixado no login; O feelover é um frio de outra região.
10) Ordem, coerência, idimpotência
A organização é garantida dentro da partição (user/room), não globalmente.
Consistência: O evento pode chegar antes da resposta REST; UX deve ser capaz de viver com uma condição intermediária (optimística UI + reconciação).
Idempotidade: O novo processamento de 'event _ id' não altera o status do cliente.
11) Erros, reconnect e «tempestade»
Códigos de fechamento: '1000' (normal), '1008' (policy), '1011' (internal), '1013' (server overload).
O backoff exponencial cliente + jitter: 1s, 2s, 4s... max 30s.
Durante os relançamentos em massa («thundering herd»), o servidor dá «retry _ after» e «cinza» com a dica de usar SSE fallback para read-only.
12) Cash and Snapshots
Cada assinatura pode começar com um estado relevante e, em seguida, com um fluxo de eventos diff.
Versionização do padrão 'data _ versão' e compatibilidade (a extensão dos campos não rompe os clientes).
13) Observabilidade e SLO
Métricas:- Conexões ativas, instaladas/segundos, distribuição por locatários/regiões.
- Entrega: p50/p95 atrasos de corretor a cliente, drop-rate, resend-rate.
- Confiabilidade: Taxa de sucesso de de m sem snapshot, detector de gap.
- Erros: 4xx/5xx no handschake, códigos de fechamento, limites-hits.
- Carga: RPS comandos 'subscribe', tamanho das filas, CPU/NET.
- Estabelecimento WS p95 ≤ 500 ms (dentro da região).
- Evento end-to-end latency p95 ≤ 300 ms (user-partition).
- Resume success ≥ 99%, message loss = 0 (по at-least-once).
- Uptime estrim-endpoint ≥ 99. 95%.
14) Gerenciamento de esquemas e versões
Dicionário de eventos com proprietários, exemplos e semântica.
Evolução suave: apenas adição de campos opcionais; remoção - depois de «@ deprecated».
Testes contratuais contra SDK cliente, linteres em JSON Schema/Protobuf.
15) Incidentes playbooks (incorporar ao seu playbook comum)
Crescimento latency: mudar as partituras para nós de reserva, aumentar o tamanho do batch do corretor e priorizar eventos vitais.
Tempestades de recôncavo: ativar 'retry _ after', elevar temporariamente os limites de handshake, ativar o folbeck SSE.
Vazamento de tokens: rotação JWKS, levantamento de tokens afetados, recall forçado com ré-auth.
Perda da particpação do corretor - transferência para o modo de súmulos, réplicas após a recuperação.
16) Mini-especificação API (simplificado)
Handshake (HTTP GET → WS):
GET /ws? tenant=acme&client=web
Headers:
Authorization: Bearer <JWT>
X-Trace-Id: <uuid>
Comandos do cliente:
json
{ "op":"subscribe", "topics":["user:123"], "resume_from":"1748852201:42" }
{ "op":"unsubscribe", "topics":["user:123"] }
{ "op":"ping", "ts":"2025-11-03T12:34:56Z" }
Respostas do servidor:
json
{ "op":"ack", "id":"subscribe:user:123" }
{ "op":"event", "topic":"user:123", "seq":"1748852201:43", "type":"balance. updated", "data":{...} }
{ "op":"snapshot", "topic":"user:123", "seq":"1748852201:42", "state":{...} }
{ "op":"error", "code":"acl_denied", "reason":"no access to topic tournament:456" }
{ "op":"pong", "ts":"..." }
17) Folha de cheque UAT
- m de off após 1/10/60 minutos de downthame do cliente.
- Deadup: a entrega repetida do mesmo 'event _ id' não altera o estado.
- Detector de gap → automático 'snapshot' e alinhamento.
- Quotas e backpressure: o cliente carregado recebe policy-disconnect.
- Multiregião: região failover com preservação off-set.
- Segurança: Tocador de toquete vencido JWT, tentativa de subscrição fora da LCA.
- RG/balanço do evento vêm antes/depois de REST - UI corretamente «costura».
18) Erros frequentes
Não 'seq/offset' e retomada - perdemos eventos e credibilidade.
Misturar comandos de pagamento críticos em mutações WS - use o REST.
Falta de backpressure/quotas - conexões «suspensas» e avalanche de memória.
A ordenabilidade global é cara e não é necessária; Há bastante ordem na partição.
Logar PII em eventos - violações de privacidade e PCI/GDPR.
Nenhum dicionário de evento ou versionagem - os clientes quebram.
Currículo
WebSocket-stream fornecem jatinhos UX e sinais operacionais se construídos como um canal resumido, protegido e limitado: WSS+mTLS/JWT, LCA em topics, seq/offset + resume, at-least-once, backpressure/quotas, corretor como fonte de verdade, observabilidade e SLO. Assim, os striptees permanecem rápidos para o usuário e controláveis para a plataforma - sem comprometimento de segurança e dinheiro.