Crypto Casino
Torrent Gear
Pruebas de carga: perfiles de jugadores y picos de tráfico
1) Por qué modelar perfiles en lugar de «temperatura media»
La carga de iGaming tiene una alta explosividad: promos/torneos/streams dan múltiples ráfagas de RPS, y la distribución de acciones es desigual (login→depozit→stavki/vyvod). La prueba debe reflejar el comportamiento de los segmentos (principiantes, VIP, «bonus hunters», móviles), de lo contrario obtendrás «gráficos verdes» e incidentes rojos.
SLO clave (ejemplo durante 30 días):- Login: éxito ≥ 99. 9%, p95 ≤ 250 ms
- Depósito: éxito ≥ 99. 85%, p95 ≤ 400 ms
- Apuesta (WS): p95 mensaje RTT ≤ 120 ms, disconnect rate ≤ 0. 5%
- Lanzamiento del juego: éxito ≥ 99. 8%, p95 ≤ 800 ms
2) Perfiles de jugadores (escenarios de comportamiento)
A. Newbie (nuevo jugador) - 25-40% de tráfico máximo
Camino: registro → inicio de sesión → ver promo → depósito (pequeñas cantidades) → lanzamiento de 1-2 ranuras
Características: alta proporción de errores de UX, pagos retraídos, saltos entre páginas
B. Regular (devuelto) - 40-50%
Manera: inicio de sesión → depósito rápido/sin depósito → 3-5 juegos → retiro raro
Características: sesión estable, sensible a p95> 200 ms en WS
C. Bonus-hunter (promoción) - 10-20% en acciones
Camino: registro → activación del bono → apuestas mínimas → intento de retiro rápido
Características: ráfagas a '/promo/claim ', abuso de retrés, frecuentes 429 sin los límites correctos
D. High-roller/VIP - ≤ 1%, pero un cheque alto
Camino: inicio de sesión → depósito importante → juegos en vivo/apuestas altas → retiro
Características: sensible a cualquier retraso/failam del proveedor de juegos, crítico SLA de pago
E. Bettor (deportes/live)- Camino: login → suscripción a cotizaciones → apuestas frecuentes en «ventanas estrechas» (hasta 10-30 s)
- Características: carga pulsante en WS/caché de coeficientes, ráfagas en goles/VAR
3) Modelos de tráfico y temporización
Open vs Closed model
Open (Poisson, arrivals/sec) - adecuado para promociones públicas y streams (los usuarios «vienen por sí mismos»).
Cerrado (fix. número de usuarios virtuales con think-time) - para sesiones estables (VIP, juegos en vivo).
Patrones de tráfico:- Ramp: aceleración lineal x1 → x5 en 10-20 min
- Burst: «explosión» x3-x10 en 30-120 s (anuncio de bonificación/premio mayor/gol)
- Onda: crestas cada 5-10 min (rondas de streaming/torneo)
- Soak: 2-12 horas de carga estable (fugas, GC, descriptores, degradación)
4) Flow crítico y métricas
Autenticación y perfil
RPS en '/login ', '/2fa/verify', p95/p99, error-rate, lock/ratelimit-works
Pagos
Gaming Gates
Inicio de la ranura/escritorio en vivo: success-ratio, time-to-first-spin, fallo del proveedor
WebSocket: conexiones en pico, mensajes/sec, RTT, rate-limit/429, reconnects/min
Promociones/Bonos
'/promo/claim ', '/freespin/activate': 200/4xx/5xx, share 409/apdates competitivos, cascadas por billetera
Almacenes y colas
Saturation: CPU, DB-connections, pool-timeouts, queue lag, GC pauses
5) Geo y realidad de la red
Distribución geográfica por mercados (EU/LatAm/MEA/APAC) y mezcla ASN (redes móviles, hosting).
Latencia edge→origin (Anycast/CDN), RTT móvil, pérdidas por lotes.
A/B: con CDN y bypass (origin) - para evaluar el backend «puro».
6) Diseño de datos de prueba
Cuentas seudonimizadas, tarjetas BIN por región, moneda, estado KYC.
Tiempos de comportamiento realistas: think-time 1-7 s para casual, 0. 3–1. 2 s para apuestas en vivo.
Control de operaciones no deseadas (retiro/depósito): modo seco para sandbox PSP, tapón de billetera.
Filtros antifraude/bot: whitelist de prueba ASN/IP/device, de lo contrario WAF/anti-bot «estrangulará» el stand.
7) Plan de pruebas (plantilla de lanzamiento/promoción)
1. Smoke-carga: 10-20% desde el pico, 30 min
2. Capacity ramp: x1 → target → x1. 5 desde el pico objetivo, 10-15 minutos por etapa
3. Serie Burst: 3-5 ondas de 60-120 s a x3-x5 desde el nivel actual
4. Soak: 4-8 h a 60-80% pico (fugas, degradación)
5. Failover/Chaos: desactivación de un único PSP/PoP, degradación del proveedor de juegos, caída de un solo shard DB
6. WS-tormenta: reconnect masivo + 5-10 mensajes × durante 2-3 minutos
7. Promo-tormenta : /promo/claim + registro + depósito en 60 segundos «ventana»
Criterios de salida: todos los SLO en la zona verde; headroom ≥ 30% por CPU/connects; No se han superado las cuotas PSP; no hay crecimiento de colas y p99 después de la prueba.
8) Patrones de infraestructura para soportar picos
Warm-pool/provisioned concurrency (funciones/contenedores), pre-scale antes de la promoción.
Conexión de pooling y límites de upstream (DB/PSP) + cola de consultas.
Idempotency keys en depósitos/webhooks.
Retroceso: 429/503 con 'Retry-After', degradación de las rutas 'heavy' (reportes/búsqueda).
Caché/edge caché de ratios y metadatos estáticos de juegos.
9) Anti-retroceso: lo que «se rompe» en primer lugar
Grupos DB abarrotados → p99 de crecimiento y tiempo de espera
Wallet-locking en apdates de balance masivo- PSP-rate limits → avalancha de retraídos y tomas
- WS-broadcast con miles de suscripciones sin bateo
- Reglas WAF demasiado agresivas → FPR en el inicio de sesión/depósito
10) Observabilidad durante la prueba
Dashboards RED/USE + embudo de negocios (login→depozit→stavka→vyvod).
Tracks end-to-end para consultas «lentas «/erróneas (100% de error de muestra).
Marcadores de fase de prueba (ramp/burst) en métricas/logs.
Paneles separados de PSP/proveedores de juegos, cola de retiros, idempotency-hits.
11) Equipo y proceso
War-room: ingeniería de perfomance, backend, SRE, riesgo/pagos, WAF/seguridad, producto.
Runbook: ¿qué hacemos en p99> objetivo, cómo bajar la carga, a quién llamar del proveedor.
Informe: SLO, ancho de banda, cuellos de botella, costo, recomendaciones de código/arquitectura/cuotas.
12) Plan Capacity: del número de jugadores al RPS
Evaluación (ejemplo):- Jugadores simultáneos en el pico: 50k
- Frecuencia media de acción: 0. 25–0. 5 req/s por jugador (móvil abajo, en vivo arriba)
- API de evaluación RPS: 12. 5k-25k + solicitudes de servicio (billetera, proveedores, caché)
- WS: 30-60k conexiones activas, 3-8 msg/s por mesa/tema
- Agregue 30-50% de headroom a burst y retrés
13) Check-list de preparación del stand
- Datos: cuentas/monederos/tarjetas/monedas/países/juegos, seudonimizados
- Aislamiento de los billetes: sandbox + tapones de webhooks, prohibición de las amortizaciones «en vivo»
- Edge/CDN/WAF como en venta; antibot en modo «suave» para pruebas ASN
- Observabilidad: dashboards, alertas, rastreo incluido
- Auto-scale y warm-pool están configurados; los límites de grupos/connects están documentados
- Bandera canaria para los «pesados» (reportes, exportaciones masivas)
14) Herramientas (puntos de referencia)
Generadores: k6, Gatling, Locust (HTTP/WS), JMeter (incluido el complemento WebSocket)
Fid emuladores: scripts personalizados de citas/proveedores de juegos
Transplay: tcpreplay/ingress-espejado con anonimización y normalización
15) Ejemplo de perfil «Torneo promocional, 60 segundos antes del inicio» (caso)
Onda de −5 min → 0:- Arrivals abiertos: 400 → 2 500 req/s (inicio de sesión/refresh)
- '/promo/claim ': bursts de 1.000 rps 3 × de 20 s
- WS: + 15k connect, + 5 msg/s sobre el tema «leaderboard»
- Pre-calentamiento de caché y warm-pool
- Rate-limit '/promo/claim ': 10/min IP, cuenta de 2/min, caché de respuestas negativas de 30 segundos
- Idempotencia y cola de bonificación (batch 50-100/tacto)
- «Suave» 429 con 'Retry-After' + progreso de IU
Criterios de éxito: no hay degradación SLO de inicio de sesión/depósito, p95 WS <150 ms, <0. 5% de errores de claim, ninguna inflación de colas.
Resumen
Las pruebas de carga de iGaming son simulaciones de comportamiento en lugar de «disparos de endpoint». Primero identifica los perfiles de SLO y jugadores, luego elige el modelo de tráfico (abierto/cerrado), construye escenarios reales de inicio de sesión/depósito/apuestas/promociones con geo y límites de PSP, prueba bursts y soak, activa la observabilidad y prepara el autocaravana. Ancla el resultado con un plan capacity y runbook 'ami, para que te encuentres con picos de tráfico sin sorpresas ni pérdidas de conversión.