Crypto Casino
Torrent Gear
Cómo funciona el failover y la copia de seguridad en iGaming
Por qué iGaming disciplina especial DR/BCP
La plataforma de casino es dinero en tiempo real (monedero/ledger), rondas en vivo (RNG/Live), pagos, afiliados y cumplimiento estricto. Cualquier «agujero» en la disponibilidad se convierte rápidamente en riesgos financieros y legales. Por lo tanto, la arquitectura se construye en torno a una recuperación predecible: objetivos conocidos, escenarios conocidos, procedimientos ensayados.
Objetivos y términos básicos
RTO (Recovery Time Objective): tiempo de recuperación del servicio.
Para monedero/ledger: ≤ 60-300 segundos (Feilover intrarregional), ≤ 15 min (DR interregional).
RPO (Recovery Point Objective): pérdida de datos permitida.
Para ledger: 0-5 segundos (réplica sincrónica/cuasi sincrónica), para reporting: ≤ 15 minutos.
SLA y Error Budget: formalizan los compromisos entre la tasa de cambio y la estabilidad.
Capas de tolerancia a errores
1) Infraestructura: Multi-AZ/Multi-Región
Multi-AZ (mínimo de 3 zonas): todos los servicios críticos se distribuyen por zonas, el failover automático de BD/bus.
Multi-Región DR: «caliente» (Active-Active) o «cálido» (Active-Passive) segunda región con aislamiento por jurisdicciones (data residency).
Solución cuando qué modo:- Active-Active: baja latencia para los jugadores en dos regiones, administrador de la región cruzada a través de la sincronización de eventos + un estricto «lugar de la verdad» para los cálculos.
- Active-Passive (warm): más fácil y más barato; pasiva mantiene instancias cálidas + réplicas de DB, pero el tráfico no sirve.
2) Red y perímetro
Duplicado ingress/WAF, Anycast o DNS Fealover con controles de salud.
Puertas de enlace separadas para cajeros y proveedores, listas de IP permitidas en ambas regiones.
3) Datos y colas
BD relacional (Postgres): Patroni/Managed HA, réplicas sincrónicas en AZ, réplica asíncrona en la región DR (con monitorización de lags). PITR con snapshots cada N minutos + archivo WAL.
OLAP (ClickHouse/BigQuery): replicación/charding; la pérdida es admisible más alta (RPO hasta 15-30 min).
Caché (Redis): un clúster con un failover, pero no una fuente de verdad; cuando se cambia - calor caliente.
Bus de eventos (Kafka/NATS): clústeres espejo y/o cross-cluster-mirroring, garantía «at-least-once», control de idempotencia en los consumidores.
4) Aplicaciones y dominios
Monedero/guardabosques: núcleo stateful con consistencia estricta, un «maestro rastreador» por región; en DR interregional, procedimiento de «escritura electada» con bloqueo de doble registro.
Juego bridge/API: stateless, failover horizontal por cheques de salud; idempotencyKey para todas las vías financieras.
Bonificaciones/notificaciones/ETL: permiten el procesamiento diferido, reiniciado desde las colas.
Caja registradora (PSP/cripta): estrategia multiproveedor (mínimo 2 rieles por país), cambio rápido de merchant/endpoints.
5) Streams en vivo
WebRTC/LL-HLS gateways con nodos edge regionales; rutas fallback en LL-HLS cuando WebRTC se degradó.
Mantener la lógica de apuestas fuera del reproductor para que el reinicio del stream no afecte al cálculo.
Failover-patterny
Activo-activo (bidireccional)
Ventajas: mínimo RTO/RPO, proximidad a los jugadores.
Contras: la complejidad del ledger y los conflictos de grabación, la red cara.
Práctica: «un escritor por dominio» + event sourcing para reproducir estados en una región vecina.
Activo pasivo (caliente)
Ventajas: equilibrio precio/dificultad.
Contras: RTO arriba, se necesita un plan de «promoción» de la región pasiva.
Práctica: Automatización + confirmación manual (principio de 4 ojos) al cambiar de billetera.
Intrarregional (Multi-AZ)
Autofailover BD/caché/ingress.
Sin cambio de DNS/Anycast, RTO segundos-minutos.
Copia de seguridad (Backup) por clase de datos
Principios:- El respaldo está cifrado en reposo y en tránsito, las claves están en KMS/HSM.
- Modo immutable (WORM) para backups críticos (protección contra borrado/cifradores).
- Directorio de backups con metadatos (versión del esquema, ventana WAL, sumas de comprobación).
- PITR es obligatorio para el ledger.
Datos e idempotencia: cómo evitar «agujeros» en el feolover
IdempotencyKey en las solicitudes 'bet. place`, `payout. request`, `cashier. webhook`.
Ledger - sólo append-only: la configuración repetida creará un registro de ajuste en lugar de «sobrescribir».
Las cerraduras transaccionales/versionamiento de equilibrio protegen contra las carreras cuando se cambia el rol de escritor.
Desduplicación de eventos (side-consumer, hash por campos clave).
Taquilla, PSP y cripta: Plan B siempre incluido
Un mínimo de dos proveedores por método de pago (tarjeta/ARM), cuentas de merchant preestablecidas en ambas regiones.
Para los stablecoins, hay dos redes (por ejemplo, TRC-20 y ERC-20) y dos proveedores on/off-ramp.
Router de pago: cuando PSP falla, cambia instantáneamente a backup, registra las razones.
Los flujos KYT/AML se duplican; si el servicio externo no está disponible - «degraded mode» con escalada manual.
Procedimientos operativos (Runbooks)
Automático
El cheque de salud de la cadena ingress → API → una billetera → un proveedor → DB.
Desactivación automática de funciones «pesadas» (torneos/misiones) cuando la cartera está degradada.
Taimouts/retraídas con pausa exponencial y deduplines estrictos.
Manual (con confirmación)
Promoción de la región DR en activo: cheques por paso, registro, plantillas comm (sapport/partners/regulador).
Compensación/VOID por rondas: códigos de causa, enlaces de vídeo, firma de los responsables.
Descongelación de pagos con doble control.
Ejercicios y pruebas de preparación
Game Day/Chaos Drill mensualmente: desconexión de AZ, degradación de la DB, caída del proveedor.
Full DR Rehearsal trimestral: elevar la región de DR «a pleno crecimiento», ahuyentar escenarios reales de apuestas/pagos.
Pruebas de restauración: restaurar el guardabosques en el momento T, conciliar con el control P&L y los cortes hash.
Table-top con cumplimiento: quién y a quién notifica qué informes se generan (regulador, PSP, afiliados).
Observabilidad y señales de Failover
SLO-métricas: p95 latency monedero, share 'bet. rejected ', tiempo de settle de la ronda, SLA de los pagos, DB de replicación de Magic, Kafka-consumers de Magic.
Eventos de conmutación: alertas «role change», «replication log> X», «object-lock violation».
Dashboards DR: rol actual de los nodos, puntuación RPO (minutos WAL), estado de la ventana PITR.
Seguridad y cumplimiento
Aislamiento de datos por jurisdicciones (EU/UK/CA/...): replicación dentro de los límites permitidos por las leyes.
Registros inmutables (S3 Object Lock/WORM), retoque según los plazos reglamentarios.
Secretos: rotación de claves, separación de responsabilidades (dual-control) para operaciones de DR.
Auditar el trail de todos los cambios y restauraciones.
Anti-patrones que rompen DR
Una PSP/una red de stablecoin por país - no hay riel de respaldo.
OLTP y OLAP en el mismo DAB: la recuperación bloquea las operaciones «en vivo».
No idempotencyKey - toma de débito/pago en retiros.
Los backups sin una prueba de restore regular son un «backup schrödinger».
Ausencia de WORM/immutabilidad: vulnerabilidad a la eliminación de información privilegiada/malintencionada.
DNS Feilover sin TTL cortos y endpoints calentados.
Un solo escritor de legger en dos regiones al mismo tiempo es una división de la fortuna.
Lista de verificación de preparación para accidentes
Arquitectura
- Multi-AZ para todos los servicios críticos, topología documentada.
- Región DR con el rol descrito (Active-Active/Passive) y el presupuesto.
Datos
- Postgres: PITR, snapshots, monitoreo, pruebas de recuperación regulares.
- Kafka/NATS: espejo/archivo, plan de réplica.
- ClickHouse/OLAP: backups por lotes, recuperación de muestras.
- S3: Object Lock (WORM), versiones, región cruzada.
Aplicaciones
- Idempotency en dinero, append-only ledger, versioning balance.
- Auto-feature-degrade en incidentes (torneos/misiones off).
- Controles canarios antes de cambiar de región.
La caja registradora y la cripta
- Dos proveedores por método y dos redes para los stables.
- Enrutamiento y registro de las causas de conmutación.
- KYT/AML en modo degrade con escalada.
Operaciones
- Runbooks con RACI y teléfonos de servicio.
- Los Días Chaos Mensuales y las enseñanzas trimestrales Full-DR.
- Patrones de comunicación (sapport, socios, regulador).
Observabilidad
- Dashboards RTO/RPO, alertas del papel de la DB, lags, fallas de apuestas/pagos.
- Auditoría-registro de conmutación y recuperación.
La fiabilidad de iGaming no es un «botón de failover», sino un sistema de hábitos: aislamiento geográfico, RTO/RPO predecibles, dinero idempotente, caja registradora multirriel, backups immutables, ejercicios regulares y comunicación transparente. Esta disciplina permite revivir fallos sin pérdidas en el ledger, sin rondas «pegadas» y sin golpes a la confianza de jugadores y reguladores.