GH GambleHub

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'.

Semântica do cliente:
  • 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.
SLO orientações:
  • 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.

Contact

Entrar em contacto

Contacte-nos para qualquer questão ou necessidade de apoio.Estamos sempre prontos para ajudar!

Iniciar integração

O Email é obrigatório. Telegram ou WhatsApp — opcionais.

O seu nome opcional
Email opcional
Assunto opcional
Mensagem opcional
Telegram opcional
@
Se indicar Telegram — responderemos também por lá.
WhatsApp opcional
Formato: +indicativo e número (ex.: +351XXXXXXXXX).

Ao clicar, concorda com o tratamento dos seus dados.