Arquitectura de casino multimarca: servicios comunes y aislamiento

Texto completo del artículo

💡 18+. Material educativo. No es una llamada al juego. El enfoque está en la ingeniería y el cumplimiento de las plataformas iGaming.

1) Tarea de plataforma multimarca

Un «esqueleto» tecnológico sirve a varias marcas/licencias/geo. El objetivo es maximizar la redundancia del núcleo (velocidad, coste) con un estricto aislamiento de riesgos y datos (dinero, PII, reporting).

Elección clave: multi-tenant (instancias comunes, «inquilinos» dentro de un solo servicio) o multi-instance (instancias individuales/DB/clústeres por marca o región). En la práctica se utiliza un híbrido.

2) Capas y bordes (esquema de referencia)

Edge / Governance

API-gateway, protección WAF/bot, filtros geo, tarifas, mesh de servicio.

Tenant/brand resolver: metadatos de marca (licencia, geo, moneda, banderas).

Domain Core (por servicios)

PAM (cuentas, sesiones, 2FA) es un multi-tenant con una división de tenant_id rígida.

Wallet/Ledger (contabilidad) - más comúnmente multi-instance per license/region.

Cashier/PSP Orchestration - pipelines/llaves individuales por marca/región.

KYC/AML - Proveedores geo-plug-in, reglas a nivel tenant.

Bonus Engine/Tournaments/Jackpots - Servicios compartibles con aislamiento de reglas.

Game Gateway es una puerta de enlace común a los proveedores con mapping de divisas por marca.

Affiliates/Commission - matemáticas generales, espacios de seguimiento separados.

RG - Límites y estados a nivel de marca/jurisdicción, señales de parada sincrónicas.

Compliance/Reporting - escaparates y descargas en la marca/licencia/región.

CMS/Front - Herramientas comunes + temas por marca/navegación.

Data & Observability

Bus de eventos (Kafka/Pulsar) con las claves 'tenant _ id/brand _ id'.

OLTP por servicio, OLAP escaparates con aislamiento de nivel rígido por marca.

Métricas/tracks/logs con las etiquetas de tenant obligatorias; SIEM/SOAR.

3) Dónde dividir, y dónde aislar

3. 1 Servicios comunes (ahorro y velocidad)

Game Gateway: integraciones unificadas con los estudios, banderas fich per brand.

Bonus/Tournament Engine: constructor general, pero «sandbox» y límites per brand.

Affiliates/Tracking: plataforma única, ID/dominios/postback separados.

KYC/Screening Orchestrator: bus compartido, diferentes proveedores de geo.

CMS/Front toolkit: temas/localización/widgets; deploy frente separado del núcleo.

BI/ETL: pipelines compartidos, escaparates separados y derechos.

3. 2 Aislamiento rígido (dinero, derecho, datos personales)

Ledger/Wallet: BD/instancias individuales para una licencia/región (a menudo incluso un clúster separado).

Cashier/PSP: claves, merchantes, enrutamiento y límites por marca/región.

PII/Residencia: los datos de los usuarios se almacenan en la región; Prohibición de solicitudes cruzadas regionales.

Compliance/Reporting: descarga reglamentaria estrictamente bajo marca/licencia.

RG/AML: las señales de parada se aplican «in situ», sin sharing intertenant.

4) Modelos de multitenencia de datos

1. Schema-per-tenant: un DB, esquemas separados. Simplemente empezar, es más difícil escalar.

2. DB-per-tenant: DB (o clústeres) individuales por marca/región. Más caro, pero más seguro.

3. Table-partitioning by tenant: tablas grandes con RLS/enmascaramiento rígido; adecuado para telemetría/registros.

4. Storage-per-jurisdiction: residencia física (EU, UK, BR...), acceso interregional prohibido en redes/ACL.

Para Ledger, generalmente se selecciona una capa de servicio independiente DB-per-license/region +.

5) Circuito monetario: invariantes y eventos

Atomicidad e idempotencia de los comandos ('wallet. debit/credit/settle ') es un contrato clave.

Outbox/CDC: publicación de eventos sincronizados de transacciones; sin «magia manual».

Sagas: depósito/depósito/bonificación - sólo a través de la orquestación, compensación por eventos individuales.

Monederos de bote separados y contribuciones transparentes por marca/grupo.

SLO para el núcleo (mínimo):

p95 monedero <150 ms; settlements perdidos/duplicados = 0.
Autorización Cashier <3 s; el éxito del depósito ≥ 85% en el geo objetivo.
Entrega de eventos a BI ≤ 5 minutos.

6) Orquesta de pago en multimarca

Pipelines per brand/market: diferentes PSP, merchantes, límites, política 3-DS.

Cascada: falla → fracaso sin perder la canasta.

FinOps: rutas por costo/conversión; Informes de conciliación de marcas a diario.

Anti-frod: velocity, comunicaciones gráficas de tarjetas/dispositivos dentro de la marca y holding (con correlación cruzada cuidadosa).

7) Juego y cumplimiento responsables

Límites de RG (depósito/pérdidas/tiempo/apuesta): configurados por marca/jurisdicción, aplicados sincrónicamente en la apuesta.

Auto-exclusión y realidad-cheques - respetan los límites de la marca y la ley de la región.

AML/KYC - Sanchlist/RR/fuente de fondos; SAR/NAT por marca.

Informe - automatizado; los Excel manuales están prohibidos como proceso.

8) Observabilidad y accesos

Trace-ID de extremo a extremo + etiquetas 'tenant _ id/brand _ id/license'.

RBAC/ABAC: los papeles "finansy/risk/sapport/marketing/komplaens" - el acceso solamente a la marca.

Audit WORM: registros inmutables de acción creta, política de «cuatro ojos».

Secretos/claves: Vault/HSM, segmentación de claves por marca/región, rotación.

9) Topologías deployas

Single Cluster, Multi-Tenant Services

Arranque rápido, ahorro apretado. Requiere RLS maduro, aislamiento de recursos y límites.

Regional Clusters + Shared Integrations

La puerta de enlace del juego y una parte de los servicios compartidos están encantando, el dinero/PII es regional. Balance de valor y cumplimiento.

Per-Brand/License Stacks

Aislamiento total (marcas VIP, altos riesgos). Caro, pero mínimo blast radius.

A menudo se combinan: un «lecho» común de integraciones y herramientas + dinero aislado/PII.

10) Acerca de los datos y directorios

Data contracts: Avro/JSON Schema + Registry; versiones semánticas.

Gobierno: catálogo de campos, propietarios, escaparates SLA, línea de origen (lineage).

RLS/Masking: reglas a nivel de almacenamiento y BI; Acceso a PII - por solicitud y token de tiempo.

Late arrivals/dedup: patrones de upsert sostenibles en OLAP.

11) Marketing, CMS y afiliados

Características Flags per brand: liberación de promos/temas/mecánicos sin efectos cruzados.

Catálogos de contenido: un solo ID de proveedores/juegos, mapping de disponibilidad a la marca/mercado.

Afiliados: dominios separados/UTM/sub-ID; anti-frod en sub-socios.

Cumplimiento de plataformas (YouTube/Twitch): etiquetado de anuncios/afiliados por marca.

12) Métricas de madurez de la arquitectura multimarca

1. Aislamiento de dinero: BD/instancias individuales para la licencia/región; cero edición manual.

2. Residencia de datos: técnicamente asegurada (políticas de ACL/red), verificada por el ejercicio.

3. Eventualidad: outbox/CDC en todas partes; los flujos alcanzan BI ≤ 5 min.

4. Pagos: la cascada PSP está activa; los informes de conciliación están automatizados.

5. RG/AML: las señales de parada se aplican sincrónicamente; informes sin pasos manuales.

6. Observabilidad: todas las métricas/registros/tracks están marcados con brand/tenant; SLO dashboards por servicios y marcas.

7. Accesos: RBAC/ABAC y «cuatro ojos» en cirugía de creta, auditoría WORM.

8. Plan DR: RPO ≤ 5 min, RTO ≤ 30 min; ejercicios regulares para cada región.

13) Check-list del arquitecto (antes del lanzamiento de la marca)

Se ha asignado 'brand _ id/tenant _ id', se han establecido claves/secretos y límites.
Ledger/Wallet - BD/clúster dedicado (si la licencia lo requiere).
Cashier - cuentas de merchant y rutas; transacciones de prueba y conciliaciones.
RG/AML/KYC - proveedores, reglas, señales de parada; escenarios de prueba.
Game Gateway - mapping proveedores/monedas/restricciones; cheque de salud.
Bonus/Tournament - sandbox y auditoría de reglas.
Affiliates - espacio, postback, anti-frod.
CMS/Front - tema, localización, fichflags; Verificación de restricciones geográficas.
BI/Reports - escaparates, accesos, descargas reglamentarias.
Observabilidad - SLO dashboards y alertas por marca/región.

14) Banderas rojas (que rompe la marca múltiple)

Un único DAB «para todos» sin RLS/enmascaramiento y sin Ledger independiente.

Correcciones manuales de balances, bonos y límites.

Llaves PSP merchant compartidas para diferentes marcas/regiones.

Publicación de eventos «más allá» de las transacciones de dominio (no outbox/CDC).

BI/informes de tablas de combate OLTP.

Ausencia de geoaislamiento de los ejercicios PII y DR.

Las reglas RG/AML se separan entre marcas sin tener en cuenta la ley local.

No hay etiquetas tenant/brand en las logias y métricas: las investigaciones se convierten en caos.

15) Resultado

La arquitectura multimarca es el equilibrio entre lo general y lo separado. Las integraciones comunes, los instrumentos y los acontecimientos aceleran el desarrollo; dinero aislado, pagos, PII e informes mantienen el cumplimiento y reducen los riesgos. La plataforma exitosa se construye en torno a tres principios:

1. Integridad monetaria y aislamiento (Ledger/Cashier per license/region, idempotencia, sagas).

2. Eventualidad y observabilidad (bus, contratos, etiquetas brand/tenant, SLO).

3. Residencia legal y accesos al mínimo (RBAC/ABAC, auditoría WORM, KMS/Vault).

Esta base permite escalar la cartera de marcas sin un crecimiento exponencial de la complejidad, de forma rápida, segura y predecible.