Arquitectura de casino core: capas, módulos, bus de datos

Texto completo del artículo

💡 18+. El material es esclarecedor. No es una llamada al juego. El objetivo es mostrar un «mapa de terreno» de ingeniería para construir o auditar el núcleo de iGaming.

1) Imagen completa: en qué consiste el casino core

Casino Core es un conjunto de servicios de dominio que proporcionan registro/identificación de jugadores, recepción/almacenamiento de dinero, cálculo de apuestas, economía de bonos, control de riesgos y cumplimiento de regulaciones. En el diagrama de arriba hacia abajo:

1. Edge-capa (perímetro exterior): puerta de enlace API, WAF/bot-protección, rate limiting, mesh-ingress de servicio, geo/filtros legales.

2. Domain-слой (бизнес-логика): PAM, Wallet/Ledger, Bonus Engine, Cashier/PSP Orchestration, Game Sessions, Risk/Anti-Fraud, RG, Jackpot/Tournaments, Affiliates, CRM/Notifications, Compliance/Reporting.

3. Capa de datos/integración: bus de eventos (Kafka/Pulsar), colas (SQS/Rabbit), CDC/Outbox, ETL/ELT (en escaparate BI), Feature Store/ML, caché (Redis), OLTP (Postgres/Oracle), OLAP (ClickHouse/BigQuery).

4. Observabilidad & SecOps: metrics/tracing/logs, SIEM/SOAR, secretos (Vault/HSM), claves y tokens, RBAC/ABAC, audit log (WORM).

2) Módulos de dominio (composición mínima requerida)

2. 1 PAM (Player Account Management)

Registro/inicio de sesión, SSO, gestión de sesiones y dispositivos, KBA/2FA.

Perfil: edad/geo/divisa/segmentos, estados RG/autoexclusión.

Restricciones: acceso a juegos por jurisdicción, banas, «cheques de realidad».

2. 2 Wallet/Ledger (circuito monetario)

Facturas multi moneda, doble entrada (debit/credit), cableado inmutable.

Transacciones atómicas de apuestas y ganancias (idempotency keys, exactly-once dentro del dominio).

Las colinas bajo giros/rondas activas; cuentas de tránsito de jackpot.

La interacción es sólo a través de comandos (comando API), la lectura es a través de proyecciones (CQRS).

2. 3 Cashier / PSP Orchestration

Enrutamiento de pagos por banda geo/bin/puntuación; cascada en caso de fallas.

3-DS/AVS/velocity-reglas; tokenización de tarjetas; on-/off-ramp para la cripta.

Conjunto de SLO: autorización ≤ 3c p95, éxito total del depósito ≥ 85% en geo.

2. 4 Sesiones de juego (integraciones con proveedores)

Creación de sesiones de juego (token handshake), validación de país/moneda/edad.

Los eventos stavka→iskhod→settlment van por el bus; El RNG y el cálculo están en el lado del proveedor.

Anti-abuce: min bet, frecuencia de giros, prohibición de cambio de denominación «dentro del trick».

2. 5 Bonus Engine

Bonus States (issued/locked/active/forfeit), Vagger, contribuciones por juegos, max bet/max cashout, dlines.

Misiones/Misiones, Friends, Cashback; compatibilidad con torneos/jackpots.

Validez rígida de las reglas en el momento de la apuesta; una historia inmutable.

2. 6 Risk / Anti-Fraud

Señales de comportamiento (velocidad de las apuestas, multi-cuentas, dispositivos/tarjetas comunes).

Reglas velocity, comprobaciones gráficas de vínculos, chargeback defense.

Reacciones: blandas (límites), rígidas (bloqueo/escalada en AML).

2. 7 Responsible Gambling (RG)

Límites de depósitos/pérdidas/apuestas/tiempo, tiempos de espera, auto-exclusión.

«Realidad-cheques» y pausas forzadas; Almacenamiento de consentimientos y registros.

2. 8 Jackpots & Tournaments

Local/red, fix/progresivo; una tasa de participación con cada tasa.

Líderes públicos; Verificación independiente de los resultados; anti-bot.

2. 9 Affiliates & CRM

Seguimiento sub-ID, atribución (CPA/RevShare/Hybrid), postback.

Segmentación, desencadenantes, reglas de suppression, omnicanal (push/e-mail/SMS).

2. 10 Compliance & Reporting

Descargas regulatorias, informes fiscales, SAR/AMB; registro de auditoría WORM.

Residencia de datos por jurisdicciones (EU/UK/BR, etc.).

3) Modelo de eventos y bus de datos

3. 1 Topics básicos (ejemplo de Kafka-Neuming)

`player. registered`, `player. kyc. status. changed`

`wallet. debit. requested/committed/failed`, `wallet. credit.`
`game. session. started/ended`, `bet. placed`, `bet. settled`
`bonus. issued/consumed/forfeited`, `wager. progress. updated`
`rg. limit. hit`, `rg. timeout. started/ended`
`cashier. deposit. requested/succeeded/failed`, `withdrawal. requested/sent`
`risk. alert. raised/closed`, `aml. case. opened`
`jackpot. contribution/triggered`, `tournament. score. updated`

Contratos: Avro/JSON Schema + Schema Registry, versioning (backward compatible), llaves estrictas de idempotencia.

3. 2 Plantilla de evento (simplificada)

json
{
"event_id": "uuid",  "event_type": "bet. settled",  "occurred_at": "2025-10-23T16:09:12Z",  "tenant_id": "brand-1",  "player_id": "p_123",  "session_id": "s_456",  "trace_id": "t_abc",  "payload": {
"game_id": "provider:slot_777",   "bet_amount": {"amount": 2. 00, "currency": "EUR"},   "win_amount": {"amount": 36. 40, "currency": "EUR"},   "bonus_impacted": true
}
}

Regla: eventos - inmutables; ajustes - por eventos compensatorios separados.

3. 3 Outbox & CDC

Todas las transacciones de dominio escriben un evento en outbox en el mismo DB → el pablisher de fondo envía al bus.

CDC (Debezium y análogos) - para subprocesos secundarios en DWH sin carga OLTP.

4) Consistencia, sagas e idempotencia

Sagas para procesos largos (depósito/depósito, verificación, recompensas de torneos).

Idempotencia de todos los equipos: 'Idempotency-Key' + deduplicación en el lado del servicio.

Estrategia de consistencia: en la cartera - estrictamente (ACID), en el resto - eventual (a través de proyecciones).

Compensación: eventos de dominio individuales, prohibición de «edición manual» en el guardabosques.

5) Datos: OLTP/OLAP, cachés, proyecciones

OLTP: Postgres/Oracle para monedero, PAM, bonos (p95 <150 ms).

Cachi: Redis para sesiones, límites, proyecciones de líderes en caliente.

OLAP: ClickHouse/BigQuery — витрины KPI (FTD, NGR, ARPPU, Retention, LTV, Wager progress, Risk flags).

Proyecciones (CQRS): búsqueda rápida por jugador/transacción (<2c), panel RG/riesgo en tiempo real.

6) Orquestación de pago: más detallada

Reglas de routing: geo, BIN, riesgo-score, carga, costo.

Cascada: PSP1 → PSP2 sin pérdida de canasta; retraerse con una pausa exponencial.

Conciliaciones: informes PSP diarios → registro de billeteras; auto-discrepancias → tickets.

7) Integraciones con proveedores de juegos

Patrón de Gateway: API de juego único, mapping monedas/fichas, cheque de salud con degradación.

Settlment: el collback entrante del proveedor → el comando de dominio wallet. settle con clave de idempotencia.

Bloqueos: mínimos; apuesta/ganancia - vapor atómico de cableado.

8) Observabilidad y SLO

Метрики: p95/p99 latency per service, error rate, saturation, business KPIs (bets/min, settle lag, deposit success).

Seguimiento: trace_id de extremo a extremo (edge→domeny→shina→konsyumery).

Registros: estructurados, con edición PII.

SLO-mínimo:

Aptime kernel ≥ 99,95%
p95 monedero <150 ms
Redes perdidas/duplicadas = 0
Tiempo de retraso de eventos hasta BI <5 min

9) Seguridad y cumplimiento

Cero-confianza: mTLS dentro de mesh, tokens de vida corta, RBAC/ABAC, el principio de los derechos más pequeños.

Secretos: Vault/HSM, rotación de claves, encriptación de datos KMS «at nat».

PCI DSS/GDPR/contrapartes locales: segmentación de entornos, tokenización PAN, DLP, registro de acceso (WORM).

Protección WAF/bot: filtros por señales de comportamiento, device-fingerprinting.

Residencia de datos: charding por región; Prohibición de las PII regionales cruzadas.

10) Disponibilidad, DR y versión de lanzamientos

Activo-activo/activo-pasivo por región; RPO ≤ 5 min, RTO ≤ 30 min.

Lanzamientos canarios/banderas de características, giros; migraciones de DB: a través de índices ghost/secundarios.

Ingeniería del caos: Feiles regulares de redes/PSP/proveedores para verificar la degradación.

11) Gestión de esquemas y calidad de datos

Contratos de datos: versionamiento de eventos (semver), pruebas contractuales de productores/consumidores.

Goverance: directorio de datos (data catalog), nivel de confianza en las fuentes, SLA de actualización de escaparates.

Calidad: deduplicación, eventos tardíos (late arrivals), actualizaciones de idempotent en OLAP.

12) Roles y accesos (Back-office)

RBAC: roles claros (finanzas, riesgo, sapport, marketing, cumplimiento).

Acción de Creta: confirmaciones de «4 ojos», registro de operaciones inmutables.

Pantalla PII: enmascaramiento; Acceso completo - mediante solicitud/tokens temporales.

13) Métricas de madurez casino core (autoestima)

1. Fiabilidad: SLO monedero/taquilla/sesiones se realizan ≥ el 99% de los días.

2. Datos: los eventos caen en BI ≤ 5 min; consistencia ledgers vs PSP ≥ 99,99%.

3. Bonos: constructor de reglas sin editar el DB; Auditoría de cambios.

4. RG/AML: señales en tiempo real; informes/descargas automatizados.

5. Incidentes: MTTR <30 min; los post mortem son públicos dentro de la empresa.

6. Pruebas: pruebas contractuales, de carga, de caos; sandbox de prueba proveedores/PSP.

14) Check-list del auditor de arquitectura

Hay outbox/CDC, el evento se publica atomicamente con la transacción.
Ledger se implementa como un libro de cableado inmutable; hay una conciliación con PSP.
Todos los equipos son idempotentes; hay desduplicación en las llaves.
Separados por OLTP y OLAP; las proyecciones no golpean la base de combate.
Los límites RG se aplican sincrónicamente al apostar; reality-check es forzado.
Game gateway se degrada a read-only/" no new sessions' en incidentes.
El plan de RD se ejercita regularmente; los backups se verifican mediante recuperación.
Se ha documentado la política de claves/secretos y su rotación.
Los informes de compliance se recopilan automáticamente (sin mano de obra Excel).
Registros de auditoría - WORM, acceso bajo el principio de los derechos más pequeños.

15) Anti-patrones («banderas rojas»)

Correcciones manuales de balances y bonificaciones en la DB.

Mezcla de API pública y privada, sin puerta de enlace API.

Registrar eventos «omitiendo» transacciones de dominio (no a través de outbox).

Monolito billetera y bonos sin idempotencia y sagas.

Un único DAB «para todo» + solicitudes de BI en el esquema de combate.

Falta de versionamiento de eventos y pruebas contractuales.

No hay registro de cambios en las reglas de bonificación y fórmulas de torneo.

Rechazos de pago sin cascada; «pruébelo más tarde» como estrategia.

No hay herramientas RG fuera de la caja; Una licencia de confianza.

Casino core es una «red» de servicios de eventos, estrictamente limitada por derechos, donde el dinero y la responsabilidad son primarios. La fuerte arquitectura se sostiene sobre tres pilares:

1. Integridad rígida del dinero (ledger, idempotencia, sagas, outbox/CDC), 2. Eventualidad y observabilidad (contratos, rastreo, SLO, vitrinas BI), 3. Seguridad y cumplimiento por defecto (zero-trust, PCI/GDPR, RG/AML).

Al construir estas bases, el operador escala el contenido, la economía de bonos y el marketing sin riesgo para el principal: el dinero de los jugadores y la reputación de la marca.