Testes de carga: perfis de jogadores e picos de tráfego

1) Por que modelar perfis em vez de «temperatura média»

A carga iGaming é altamente explosiva: os torneios/torneios/striptease oferecem múltiplos picos de RPS e a distribuição de ações é desigual (login→depozit→stavki/vyvod). O teste deve refletir o comportamento dos segmentos (novatos, VIP, bónus-hunters, celulares), senão você terá «gráficos verdes» e incidentes vermelhos.

SLO chave (exemplo de 30 dias):

Login, sucesso ≥ 99. 9%, p95 ≤ 250 ms
Depósito, sucesso ≥ 99. 85%, p95 ≤ 400 ms
Aposta (WS): p95 Mensagem de RPT ≤ 120 ms, disconnect rate ≤ 0. 5%
Lançamento do jogo: sucesso ≥ 99. 8%, p95 ≤ 800 ms

2) Perfis de jogadores (cenários comportamentais)

A. Newbie (novo jogador) - 25-40% de tráfego de pico

Caminho: inscrição login visualização do depósito promocional (pequenas quantias) lançamento de 1-2 slots

Características: alta proporção de erros UX, retais de pagamentos, saltos entre páginas

B. Regular (retorno) - 40-50%

Caminho: login depósito rápido/sem depósito para 3-5 jogos saída rara

Características: sessões estáveis, sensível a p95> 200 ms em WS

C. Bónus-hunter (promo) - 10-20% em promoções

Caminho: inscrição → ativação do bónus → taxas mínimas → tentativa de saída rápida

Características: picos a '/promo/claim ', abuso de retais, frequentes 429 sem limites corretos

D. High-roller/VIP - ≤ 1%, mas cheque alto

Caminho: Login Grande Depósito Jogos

Características: sensível a qualquer atraso/feedback do provedor de jogos, crítico de pagamento SLA

E. Bettor (esporte/lave)

Caminho: login de subscrição de cotação apostas frequentes em «janelas estreitas» (até 10-30 c)
Características: carga de pulso WS/dinheiro de coeficientes, saltos de gol/VAR

3) Modelos de tráfego e timing

Open vs Closed model

Open (Poisson, arrivals/sec) - adequado para pros públicos e striptease (usuários «vêm sozinhos»).

Closed (fix. Número de usuários virtuais com think-time) - para sessões estáveis (VIP, jogos de lave).

Tráfego-Pattern:

Ramp: aceleração de linha x1 → x5 em 10-20 min
Burst: «explosão» x3-x10 para 30-120 s (anúncio de bónus/jackpot/gol)
Wave: Pente a cada 5-10 min (estrim/rodadas de torneio)
Soak: 2-12 horas de carga estável (vazamentos, GC, descriptores, degradação)

4) Flow e métricas críticos

Autenticação e perfil

RPS em '/login ', '/2fa/verify', p95/p99, erro-rate, lock/ratelimit-trabalho

Pagamentos

`/payments/deposit	withdraw 'por provedores: sucess-ratio, p95/p99, salsichas, idempotação
Restrições PSP (per-merchant RPS/transação por minuto), fila de retais

Gates de jogos

Iniciar slot/lave desktop: sucess-ratio, time-to-first-spin, falha do provedor

WebSocket: conexões no pico, mensagens/segundos, rate-limit/429, reconnatti/min

Promoção/bônus

'/promo/claim ', '/freespin/activate': 200/4xx/5xx, participação 409/updates competitivos, cascatas por carteira

Armazéns e filas

Saturation: CPU, DB-connections, pool-timeouts, queue lag, GC pauses

5) Geo e a realidade da rede

Distribuição geográfica de mercado (EU/LatAm/MEA/APAC) e mix ASN (redes móveis, hospedagens).

Latência edge→origin (Anycast/CDN), Mobile RPT, perdas em lote.

A/B: com CDN e contornado (origin) - para avaliar o backand «puro».

6) Design de dados de teste

Contas pseudônimas, cartões BIN por região, moeda, estado KYC.

Timing comportamental realista: think-time 1-7 s para casual, 0. 3–1. 2 c para apostas ao vivo.

Controle de Operações Não-Ideais (Saída/Depósito): Modo Seco para SSP sandbox, Portagem de Carteira.

Filtros anti-frod/bot: whitelist ASN/IP/device de teste, ou o WAF/anti-bot «estrangulará» o estande.

7) Plano de testes (modelo de lançamento/promoção)

1. Carga Smoke: 10-20% do pico, 30 min

2. Capacity ramp: x1 → target → x1. 5 do pico de destino, 10-15 minutos por estágio

3. Série Burst: 3-5 ondas para 60-120 c para x3-x5 do nível atual

4. Soak: 4-8 h para 60-80% do pico (fuga, degradação)

5. Failover/Chaos: desativação de um PSP/PoP, degradação do provedor de jogos, queda de um banco de dados

6. Tempestade WS: reconnect em massa + 5-10 x mensagens em 2-3 min

7. Pró-tempestade : /promo/claim + registro + depósito em 60-segundos «janela»

Critérios de saída: todos os SLO na área verde; headroom ≥ 30% por CPU/conectórios; As quotas PSP não foram ultrapassadas; Não há filas e p99 após o teste.

8) Pateras de infraestrutura para suportar picos

Warm-pool/procurioned concurrency (funções/contêineres), pré-scale antes da promoção.

Conexion pooling e limites de upstream (DB/PSP) + filas de consulta.

Idempotency keys para depósitos/webhooks.

Backpressure: 429/503 com 'Retry-After', degradação de rutos 'pesados' (repostos/buscas).

Cash/edge-dinheiro de coeficientes e metadados estáticos de jogos.

9) Anti-regresso: o que «quebra» primeiro

Poulas DB cheias → p99 e temporários

Wallet-locking para updates de balanço em massa

PSP-rate limits → avalanche de retrações e dublagens
WS-broadcast para milhares de assinaturas sem batching
Regras WAF muito agressivas → FPR no login/depósito

10) Observação durante o teste

Dashboards RED/USE + vórtices de negócios (login→depozit→stavka→vyvod).

Trailers end-to-end para «perguntas lentas «/erradas (100% sample erros).

Marcadores de etapas de teste (ramp/burst) em métricas/logs.

Painéis individuais PSP/provedores de jogos, fila de retrações, hits idempotency.

11) Comando e processo

War-room: engenharia perfomance, backend, SRE, risco/pagamento, WAF/segurança, produto.

Runbook: O que fazemos com p99> alvo, como baixamos a carga de trabalho, o que chamamos de provedor.

Relatório: SLO, largura de banda, estreitos, custo, recomendações de código/arquitetura/quotas.

12) Plano de Capasiti: de número de jogadores para RPS

Avaliação (exemplo):

Jogadores simultâneos no pico: 50k
Média de ação: 0. 25–0. 5 req/s por jogador (celular abaixo, live acima)
API de avaliação RPS: 12. 5k-25k + consultas de serviço (carteira, provedores, dinheiro)
WS: 30-60k conectórios ativos, 3-8 msg/s para a mesa/tema
Adicione 30-50% headroom em burst e retrai

13) Folha de cheque de preparação do estande

Dados: contas/carteiras/cartões/moedas/países/jogos, pseudônimos
Isolamento de pagamento: sandbox + aberturas de webhooks, proibição de cancelamentos «ao vivo»
Edge/CDN/WAF como em venda; antibot no modo «suave» para ASN de teste
Observabilidade: dashboards, alertas, traçado incluído
Scale automático e warm-pool configurados; limites de pool/conectório documentados
Bandeira canarela para «pesados» (repostos, exportação em massa)

14) Ferramentas (orientações)

Geradores: k6, Gatling, Locust (HTTP/WS), JMeter (incluindo WebSocket plugin)

Emuladores de fid: Caixas de customa de cotas/provedores de jogos

Tráfego Replay: Ecrã tcpreplay/ingress com anonimato e normalização

15) Exemplo do perfil «Torneio promocional, 60 segundos para o início» (mala)

Onda - 5 min → 0:

Open arrivals: 400 → 2 500 req/s (login/refresh)
'/promo/claim ': bursts por 1 000 rps 3 x 20
WS: + 15k connect, + 5 msg/s sobre «líder»

Disposição:

Pré-gravação do cachê e warm-pool
Rate-limit '/promo/claim ': 10/min IP, 2/min conta, 30-segundos de dinheiro negativo
Idempotidade e fila de pagamento de bónus (batch 50-100/tacto)
«Suave» 429 s 'Retry-After' + progresso UI

Critérios de sucesso: sem degradação do login/depósito SLO, p95 WS <150 ms, <0. 5% de erros claim, sem inflar filas.

Currículos

O teste de carga é uma simulação comportamental, não um «tiro de endpoint». Primeiro identifique o SLO e os perfis dos jogadores, depois selecione o modelo de tráfego (open/closed), construa cenários reais de login/depósito/aposta/promoção com geo e limites PSP, teste bursts e soak, inclua observabilidade e prepare o scale automático. Selecione o resultado com um plano de capasiti e runbook 'ami, para que você encontre picos de tráfego sem surpresas ou perdas de conversão.