Cómo se arregla la arquitectura del backend del casino

1) Imagen completa: dominios y flujos de datos

Dominios clave:

Identity & Accounts - Registro, autenticación, roles, dispositivos, sesiones.
Wallet & Ledger - cuentas en efectivo, monederos de bonificación, transacciones, ledger (append-only).
Gaming & Bets - sesiones de juegos, apuestas, rondas, cálculo de resultados, integración (RNG/Live/Crash, etc.).
Bonuses & Promotions - freespins, cashback, vales, wagering (apuestas), anti-abuse.
Payments (Cashier) - ramp/off-ramp: tarjetas, APM, cript/stablecoins, KYC-link.
KYC/AML/KYT & RG - Verificación de identidad/dirección/ingresos, detección de transacciones, límites y tiempos de espera.
Risk & Compliance - límites de apuestas/pagos, listas de sanciones, geo-bloqueo, auditoría.
Catalog & Lobby - lista de proveedores, juegos, categorías, límites; Opciones A/B.
Reporting & BI - P&L, GGR/NGR, retención, ciclo de vida del jugador, afiliados.
Observability & Ops - logs, métricas, trazados, alertas, señales de frod.

Orquestación: la plataforma moderna se construye con event-driven: los servicios intercambian eventos a través de un bus (Kafka/NATS), las operaciones críticas se linealizan (monedero/ledger), los subsistemas laterales se firman y responden asincrónicamente (bonos, BI, notificaciones).

2) Modelo laminado

Edge capa: puerta de enlace API, protección WAF/bot, rate limits, filtros geo/IP, banderas de características.

Capa de servicio: microservicios independientes por dominio; contratos sincrónicos - sólo donde se necesita consistencia instantánea (por ejemplo, débito de billetera al apostar).

Bus de eventos: principales eventos empresariales ('bet. placed`, `round. settled`, `bonus. issued`, `kyc. verified`, `payout. requested`).

Datos: OLTP (Postgres/MySQL) para transacciones; KV/Cache (Redis) para períodos de sesiones/límites; Almacenamiento de objetos (S3) para registros y exportaciones; OLAP (ClickHouse/BigQuery) para análisis.

3) Monedero y guardabosques: el corazón de la plataforma

Principios:

Append-only ledger: cada transacción financiera es un registro con tipo, cantidad, moneda, referencia a la fuente (apuesta, bono, depósito).
Los balances de efectivo y bonificación están espaciados. No puedes «mezclar» dinero y bonos; se utiliza la política de fuentes de fondos.
Atomicidad debet→kredit: apuesta = débito en efectivo o billetera de bonificación + creación hold; el cálculo de la ronda quita hold y hace crédito/débito sobre el resultado.

Ejemplo de transacciones en una apuesta:

`LEDGER: HOLD` (−10. 00 EUR, source: cash, ref: betId)
`LEDGER: SETTLE_DEBIT` (−10. 00 EUR) + `LEDGER: PAYOUT` (+36. 00 EUR) - si WIN
`LEDGER: HOLD_RELEASE` (+10. 00 EUR) - si VOID/PUSH

Requisitos:

Operaciones idempotentes (claves de idempotencia por 'requestId').
Versionar el balance (bloqueo optimístico) para protegerse de las carreras.
Moneda de cálculo clara y fijación de tipos en las conversiones.

4) Integraciones con proveedores de juegos

Patrones de billetera:

Seamless - Balance del operador; la apuesta/cálculo va a través de nuestra API en tiempo real.
Transfer - depósito en el banco del juego con el proveedor; más fricción, pero menor es el requisito para el aptime de la cartera.

Rutas sincrónicas (críticas):

`bet. place '→ pre-auth en la cartera (hold) →' accepted/rejected '.

Rutas asíncronas:

`round. settle 'del proveedor (webhook/WS) → settle en ledger → evento en bus → informes/bonos.

Estandarización a través del puente: esquemas de eventos únicos e identificadores 'roundId/betId', tabla de mapeo de límites y side-bets, normalización de errores.

5) Bonos, wagering y anti-abuse

Modelos: bonos de depósito, giros gratis, devoluciones (cashback), misiones, torneos.

Wagering: el progreso de la apuesta se almacena por separado; regla de «qué apuestas se cuentan» (porcentajes por categoría de juego).

Prioridad de cancelación: primero los fondos de bonificación, luego los reales - o viceversa, estrictamente por política.

Anti-patrones del jugador: apuestas en resultados opuestos, apuestas mínimas para el progreso de la granja, transferencia entre juegos con diferentes escalas - atrapado por reglas y puntuación.

6) KYC/AML/KYT и Responsible Gaming (RG)

KYC: verificación de ID/dirección/edad; los estados controlan los límites (depósito/withdraw/betMax).

AML/KYT: detección de canales de pago y direcciones on-chain (para la cripta), listas de sanciones, fuentes de fondos.

RG: límites diurnos/semanales, tiempos de espera, auto-exclusión; las comprobaciones de bloqueo se realizan antes de 'bet. place` и `payout. request`.

7) Caja registradora: depósitos y pagos

Depósitos: proveedores de tarjetas/ARM, cripta/stables, métodos locales; confirmaciones webhook; protección contra riesgos charjback.

Pagos: colas, límites, principio de 4 ojos para grandes cantidades; fuentes de fondos → «sólo el saldo cash».

Criptas de ramp/off-ramp: conversión automática, direcciones KYT, cobertura de exposición.

8) Límites, riesgos y normas regionales

Perfiles de límite ('DEFAULT', 'VIP _ A', 'VIP _ B', 'ULTRA') por país/moneda/CUS.

Geo-blocking sobre IP/GPS/documento.

Superposiciones por juegos/categorías, prohibiciones de proveedores en las jurisdicciones.

Respuesta a anomalías: picos de apuestas, correlación de dispositivos/pagos, muchos «VOID» de un solo usuario.

9) Observabilidad y explotación

Métricas: retrasos en la cartera, fallas en las apuestas, tiempo de cálculo de la ronda, conversión de depozita→stavka, GGR/NGR, pago de SLA, participación en las apuestas de bonificación.

Logs y trazados: correlación 'traceId' en todos los eventos; almacenamiento de eventos crudos en una bóveda «fría».

Alertas: degradación de la respuesta de la cartera, estallido de 'VOID', error de reconcir informes, crecimiento de 'RG _ BLOCKED'.

Runbooks: procedimientos claros de incidentes (caída del proveedor, rassinhron ledger, cancelación de rondas).

10) Seguridad y privacidad

Auth: JWT/opaque tokens short-lived, rotación de claves ('kid'), mTLS a integraciones críticas.

Políticas de acceso: separación estricta de roles (operaciones, finanzas, sapport), 2FA; para grandes pagos - okey en segunda persona.

Privacidad de datos: cifrado PII, tokenización de datos de pago, minimización del almacenamiento; GDPR/eliminación bajo petición.

Auditoría: registros inmutables, firma de eventos críticos, exportación para el regulador.

11) Escalamiento y tolerancia a fallas

Los servicios de Statles detrás del patinador de automóviles; shard horizontal para tablas calientes (apuestas, registros de eventos).

Ledger: stock vertical + replicación para lectura/reporting; «congelar» los esquemas de migración a través de tablas de sombras.

Almacenamiento en caché: Redis con TTL y estrategias «de dos pasos» (leer a través de los eventos).

DR/HA: multi-AZ, backups con recuperación regular, RPO/RTO a nivel de requisitos regulatorios.

Los modos de degradación son: taquilla sin conexión, desconexión de bonificaciones «pesadas», traducción de juegos en vivo a mantenimiento cuando el bus no está disponible.

12) Contratos y ejemplos

Apuesta (sync, JSON/NAT o gRPC):

json
POST /bets/place
{
"requestId": "9a7f-…",  "playerId": "p_123",  "wallet": "cash",
"roundId": "R-2025-10-17-19:20:05-PRAGM-Table12",  "gameId": "pragm_live_roulette",  "selection": [{"market":"straight","value":"17"}],  "stake": {"amount":"10. 00","currency":"EUR"},  "device": {"ip":"203. 0. 113. 5","ua":"Mozilla/..."}
}

Respuesta:

json
{
"status": "ACCEPTED",  "betId": "bet_8cd…",  "balanceAfter": "245. 30",  "hold": "10. 00",  "limits": {"maxBet":"5000. 00"}
}

Evento de bus (async):

json
{
"event":"round. settled",  "roundId":"R-2025-10-17-19:20:05-PRAGM-Table12",  "bets":[{"betId":"bet_8cd…","outcome":"WIN","stake":"10. 00","payout":"360. 00"}],  "playerId":"p_123",  "ts":"2025-10-17T19:20:09. 231Z",  "traceId":"tr_5f1…"
}

13) Anti-patrones (que rompe la plataforma)

Mezcla de bonos y efectivo en una sola transacción sin fuentes.

Tokens de larga vida y almacenarlos en el cliente.

Falta de idempotencia en operaciones críticas (toma de débito).

Informe monolítico de SQL sobre la DAB de combate (OLAP vs. OLTP).

Poder ciego al proveedor sin reconcir ni límites.

No hay estándar de tiempo (UTC en todas partes!) en identificadores de rondas e informes.

Las llamadas sincrónicas en dominios no financieros (bonificaciones/notificaciones) bloquean la apuesta.

14) Lista de comprobación de inicio de backend casino

Finanzas y billetera

Ledger append-only, idempotencia, versión de balance.
Separación cash/bonus, política de fuentes.
Los cursos/conversiones se registran durante la operación.

Integración de juegos

Contrato único de apuestas/liquidación, formato 'roundId/betId'.
Seamless-monedero por defecto; Transfer - sólo donde está justificado.
Scripts automáticos VOID/REFUND.

KYC/AML/RG

Políticas previas a la admisión a la tasa/pago; estados KYC ↔ límites.
KYT para la cadena on-chain, cribado de sanciones, almacenamiento de base probatoria.

Caja registradora

Webhooks/firmas, tomas/retraídas, reconcile con proveedores PSP/cripto.
4-eyes para pagos importantes, registro de acciones de los operadores.

Observabilidad

Métricas de billetera, latencia round-settle, rebote de apuestas, pagos SLA.
Tracks end-to-end (traceId), alert, runbooks.

Seguridad

mTLS/HMAC, JWT con TTL corto, rotación de claves.
Roles/Derechos, 2FA, tokenización de datos de pago.

Datos

Separación de OLTP/OLAP, CDC en DWH, S3 para eventos crudos.
Backups y pruebas de recuperación regulares.

15) Resultado

La arquitectura de backend casino es un núcleo riguroso de dinero y apuestas con consistencia lineal y un periférico flexible en los eventos: bonos, análisis, comunicaciones. El éxito no está determinado por el número de microservicios, sino por la disciplina: límites de dominio claros, un ledger sin «magia», idempotencia, observabilidad y cumplimiento por defecto. Con esta base, la plataforma se escala por país/moneda/proveedor y soporta cargas sin comprometer la seguridad y el dinero.