Por qué los casinos cambian a arquitectura modular

Por qué casino modularidad

El histórico monolito frena el crecimiento: cada cambio tira de la liberación de todo el sistema, la integración de proveedores y PSP golpea el SLO, los apdates de cumplimiento - en todo el código. La arquitectura modular (domain-driven + APIs contractuales + eventos) permite:

Retire rápidamente los fichas y conecte a los proveedores sin coordinar «todos con todos»;
Escalar selectivamente (vídeo en vivo separado de la caja registradora, billetera separada del catálogo de juegos);
Aislar los riesgos (un error en la promo no valora la cartera);
Cumplir con las licencias (lógica/versiones/políticas dentro de los límites de dominio);
Reduzca el TCO mediante contratos claros, reutilización y automatización.

Mapa de dominios (ejemplo de desglose)

Wallet/Ledger - dinero, monedas de cobertura, balances de bonificación, PITR, auditoría.

Cashier/Payments - PSP, ramp/off-ramp, KYT, webhooks idempotentes.

Puente de juego - adaptadores de proveedores, normalización round/bet.

Catalog/Lobby - juegos, proveedores, fiechering y reglas de exhibición.

Promo/Bonus - reglas de acciones, vales, wager.

KYC/AML/RG - verificación de identidad, sanciones/RR, límites y auto-exclusión.

Experiencia - Frontend, CDN, i18n, A/B, Telegram WebApp.

Telemetry/Analytics - Eventos, escaparates, ML/IA.

Compliance & Audit - Informes MGA/UKGC, archivo WORM.

💡 Cada módulo tiene su propio esquema de datos, API y contrato de eventos; interacción - a través de un bus de eventos e interfaces estrictamente versionadas.

Principios de la arquitectura modular

1. Límites DDD (bounded context). Una clara propiedad de los datos y la lógica.

2. API-primero + eventos. OpenAPI/AsyncAPI, JSON-Schema, pruebas contractuales.

3. Versificación y compatibilidad. 'v1 → v1. 1 → v2` (expand→migrate→contract).

4. Idempotency & Exactly-once-intent. Claves de consulta, deduplicación de eventos.

5. Seguridad predeterminada. mTLS, firmas HMAC, JWT corto, RBAC/ABAC.

6. Lanzamientos independientes. Canario/blue-green deploy, las migraciones de «dos escritores» están prohibidas.

7. Observabilidad. 'TraceId' de extremo a extremo, métricas de SLO por módulo.

8. Banderas de Ficha. Tráfico/segmentos geo/user, retrocesos seguros.

Capa de integración: cómo conectar proveedores y PSP

Adaptador/patrón de puente: cada proveedor de juegos/pagos es un plugin con un solo contrato de plataforma.

Juegos: normalización de 'roundId/betId/status', errores de mapeo, caché de límites.

Pagos: interfaz única 'authorize/capture/refund/payout', webhooks con idempotencia.

Desconexión: el adaptador defectuoso se traduce en mantenimiento sin afectar a otros.

Ejemplo de contrato (fragmento OpenAPI):

yaml post /wallet/debit:
requestBody:
content:
application/json:
schema:
$ref: '#/components/schemas/DebitRequest@v1'
responses:
'200': { $ref: '#/components/schemas/DebitResult@v1' }
'409': { description: IDEMPOTENT_REPLAY }

Eventos como «sistema circulatorio»

Bus (Kafka/NATS) → eventos:

`bet. placed`, `round. settled`, `payout. requested/approved`, `kyc. verified/failed`, `rg. limit_set`, `bonus. issued/consumed`, `cashier. webhook. received`, `wallet. hold/release`, `alert. slo_breach`.

Reglas:

Los eventos no cancelan el pasado; ajustes - por eventos compensatorios separados.
Cada módulo sólo escribe sus eventos originales, derivados - como nuevos temas.

Datos: capas y consistencia

OLTP por módulo: Postgres/MySQL/KeyDB - Transacciones aisladas.

OLAP/escaparates: ClickHouse/BigQuery se construyen a partir de eventos; OLTP y análisis no se mezclan.

Feature Store/ML: capa independiente de OLTP con versiones fich y TTL.

Consistencia: estratégicamente eventual entre módulos, y para el dinero, acciones locales ACID + idempotentes en las fronteras.

Deploy y zoom

Contenedores (Docker/K8s): scale automático por módulo (wallet - CPU/IO; vídeo en vivo - red; bridge — RPS).

Aislamiento perimetral: políticas de red, secretos/claves individuales por módulo, diferentes almacenes de PII/dinero/telemetría.

Tráfico-Shaping: banderas de ficha, cuota canaria, rutas regionales.

DR/HA: Multi-AZ; activo-pasivo para dinero, activo-activo para lectura/medios de comunicación.

Cumplimiento de «coser» en módulos

KYC/AML/RG es un módulo propio con políticas y un registro de soluciones ('policyVer').

Audit/WORM es un repositorio inmutable de eventos de dinero/rondas/pagos.

Informes - Exportaciones por jurisdicciones (MGA/UKGC), SLA por integridad/puntualidad.

Hilos de muestra

Tasa → liquidación → pago

1. 'gaming-bridge' envía 'bet. placed` (idempotent).

2. 'wallet' hace 'hold' y publica' wallet. hold`.

3. 'gaming-bridge' obtiene el resultado del proveedor → 'round. settled`.

4. 'wallet' cuenta 'settle' (release/payout) → 'wallet. settled`.

5. 'promo' consume eventos y devuelve el bono → 'bonus. issued`.

Caja registradora (depósito)

1. 'cashier' crea 'payment. intent` с `Idempotency-Key`.

2. PSP llama al webhook → 'cashier. webhook. received`.

3. `wallet. credit 'de hecho → un evento para los analistas y RG.

Cambios sin tiempo de inactividad (expand→migrate→contract)

1. Expand: ha añadido campos/endpoint a 'v1. 1 ', los viejos clientes no se rompen.

2. Migrar: los consumidores leen lo nuevo, escriben en ambas versiones (dual-write sólo para no-dinero).

3. Contrato: anunció EOL 'v1. 0 ', eliminado en N semanas según el plan.

Ingeniería de plataformas

Patas de oro: plantillas de módulos (repo-asceleón, CI/CD, alertas, SLO, secretos).

Pruebas contractuales: pruebas de Nat/AsyncAPI en CI; entorno de integración con proveedores falsos.

Directorio de servicios (Backstage): quién es el propietario, SLA, versiones de API, incidentes de rukbooks.

Métricas de éxito de modularidad

Lead time desde la idea hasta el lanzamiento prod ↓ por X veces.

Frecuencia de lanzamientos por módulo de ↑ (por día/semana), change-fail rate ↓.

MTTR sobre incidentes de ↓ (debido al aislamiento).

Infra costo/GGR es estable o ↓ en el aumento del tráfico (skale electoral).

Tiempo de integración del proveedor/PSP (desde el briefing al prod) ↓.

Anti-patterny

«Microservicios por microservicios». Sin límites de datos claros, la conectividad y la complejidad aumentan.

Diagramas/DB comunes entre módulos. Mata el aislamiento y los lanzamientos independientes.

Eventos sin versión/contrato. Rompen a los consumidores «tranquilamente».

Dual-write para el dinero. El riesgo de incoherencia es sólo pasos idempotentes a través de un solo escritor.

Una «capa de utilidad» global con todo en fila. Se convierte en un monolito oculto.

No hay banderas ficha y kill-switch. Cualquier error golpea a todos de inmediato.

Mezcla OLTP/OLAP. Los informes frenan las apuestas/billetera.

Sin observabilidad. No hay nada que medir el SLO y relacionar los incidentes.

Lista de comprobación de la transición a la arquitectura modular

Estrategia y dominios

Se han definido contextos bounded, propietarios y KPI por módulo.
Mapa de interacciones: API/eventos, criticidad y SLO.

Contratos y seguridad

OpenAPI/AsyncAPI + JSON-Schema; versión y ciclo de vida.
mTLS/HMAC, JWT corto, RBAC/ABAC en las fronteras.

Datos

Separados por OLTP; eventos - fuente para OLAP.
Idempotency en API/webhooks, deduplicación de mensajes.

CI/CD y lanzamientos

Canario/azul-verde, banderas de ficha, auto skale por módulo.
Pruebas contractuales en CI; un entorno con proveedores falsos.

Observabilidad

Logs/métricas/tracks con 'traceId'; SLO-dashboards.
Alertas por métricas de negocio (VOID, reject, payout lag).

Komplaens

Archivo WORM de dinero/rondas, exportación de informes regulatorios.
KYC/AML/RG como módulo independiente con registro de soluciones.

Mini ejemplos

Evento 'round. settled@v1`:

json
{
"event":"round. settled",  "v":"1",  "roundId":"R-2025-10-17-evo-23",  "gameId":"evo_blackjack_23",  "bets":[{"betId":"b_92f","playerId":"p_1","stake":"10. 00","payout":"15. 00","outcome":"WIN"}],  "ts":"2025-10-17T14:23:13. 120Z",  "traceId":"tr_5f1"
}

Billetera idempotente:

http
POST /wallet/settle
X-Idempotency-Key: 9a7f-2b1c
{
"roundId":"R-2025-10-17-evo-23",  "operations":[{"playerId":"p_1","delta":"5. 00","currency":"EUR"}]
}

La arquitectura modular transforma la plataforma de casino de una «cosechadora frágil» en una composición de dominios fiables: cada uno con sus propios contratos, datos y SLO. Esto acelera las integraciones y lanzamientos, permite una escala selectiva, simplifica el cumplimiento y reduce el riesgo de incidentes. Comience resaltando los límites de dominio, los contratos y los eventos, tejer la seguridad y la observabilidad, y obtendrá una plataforma que crezca con el producto en lugar de frenarlo.