Sectores / Gaming y esports

Wallets y pagos para la competición en directo.

En la competición en directo, cada segundo de caída queda a la vista de las cámaras. Construimos las wallets en evento, los pagos y el antifraude que se mantienen rápidos y disponibles mientras miles de personas operan a la vez.

En los esports en directo, cada tirón sale en cámara, y miles de wallets se activan en los mismos sesenta segundos.

El problema de los esports

La restricción

Las caídas ocurren en cámara.

El público ve cada tirón y miles de wallets operan en los mismos minutos. Construimos sistemas de pagos y wallets de baja latencia y alta disponibilidad, con scoring antifraude en el flujo: lo bastante rápidos para sentirse instantáneos y lo bastante sólidos para aguantar una avalancha coordinada.

  1. 01Wallets de baja latencia que se sienten instantáneas
  2. 02Alta disponibilidad ante una avalancha sincronizada
  3. 03Scoring de fraude y riesgo en el flujo de la transacción
  4. 04Datos en tiempo real para la retransmisión y la sala de operaciones
Maqueta de navegador de una consola de operaciones en directo del torneo de la ficticia Volta Invitational: franja de KPI con 4.213 TPS, latencia p95 de 141 ms, cero transacciones perdidas resaltado en verde, 212 bloqueos por fraude y 28 instancias de wallet; un gráfico de barras de TPS de 15 minutos con un pico en la victoria en la prórroga, un panel de scoring de riesgo con bloqueos por regla y una tabla de servicios con medidores de CPU y cola a cero.

Operaciones

El día del torneo, bien diseñado.

Apertura de puertas
Se aprovisionan cuentas y wallets
Los asistentes se registran y recargan en un pico previo al evento: la primera prueba de carga del día, absorbida antes de que empiece un partido.
Salto inicial
Arranca la retransmisión
Clasificaciones y estadísticas en tiempo real alimentan el stream con datos de menos de un segundo, directamente desde los mismos sistemas que procesan los pagos.
El pico
Una jugada enciende al público
Miles de transacciones llegan en segundos; la capa de wallets escala horizontalmente y nunca bloquea la cola.
Ataque
El fraude prueba suerte
El scoring de riesgo se ejecuta en el flujo de la transacción y frena el abuso coordinado sin ralentizar el juego legítimo.
Payout
Se apagan las luces
La liquidación y el pago de premios se concilian sin desajustes con el libro mayor del evento: un cierre cuadrado, esa misma noche.

Sobre el terreno

El pico de las 21:42, contenido: 4.213 TPS, p95 de 141 ms con un presupuesto de 200 ms, 0 transacciones perdidas y scoring de riesgo integrado en 4 ms.
La noche, conciliada con 0,00 € de desviación: 120.000 € en premios por SEPA antes de que se apaguen las luces.
Una wallet de evento que sigue el ritmo del público: pago por contacto en 0,14 s, recarga antes de la avalancha del descanso y el saldo sin gastar se reembolsa solo.
Datos de nivel broadcast con un feed de 0,4 s: marcador, clasificación e historial de rondas directamente desde los mismos sistemas que procesan los pagos.

Resultados

Cómo construimos para la competición en directo.

El listón que debe superar todo proyecto de gaming y esports.

<200ms
Latencia de transacción
0
Transacciones perdidas
24/7
Alta disponibilidad
Tiempo real
Clasificaciones y datos

Capacidades

Lo que construimos.

  • Wallets y pagos en el evento
  • Valor almacenado y recargas
  • Antifraude y scoring de riesgo
  • Identidad y seguridad de las cuentas
  • Clasificaciones y datos en tiempo real
  • Servicios de baja latencia y alta disponibilidad
  • Paneles de operaciones en vivo
  • Liquidación y pago de premios
  • Feeds de datos para la retransmisión
  • Hardware y credenciales a medida

Bajo carga

El pico y cómo lo aguantamos.

El pico
  • Miles de transacciones en segundos
  • Una avalancha sincronizada en un solo instante
  • Fraude coordinado que busca grietas
  • Un público pendiente de cada milisegundo
Cómo lo aguantamos
  • Servicios de wallet con escalado horizontal
  • Presupuestos de latencia tratados como prioridad absoluta
  • Scoring de fraude en línea, no a posteriori
  • Failover ensayado antes de que se enciendan las luces

¿Vas a construir algo así?

Cuéntanos las restricciones: disponibilidad, cumplimiento, condiciones de campo. Volveremos con una arquitectura que encaje.