Data Mesh: modelo de datos federado

(Sección: Tecnologías e Infraestructura)

Resumen breve

Data Mesh es un modelo organizativo y técnico donde los datos se consideran como productos de comandos de dominio y la función central de la plataforma es proporcionar autoservicio, estándares y cumplimiento. Para iGaming, esto significa: el equipo de Payments posee "Deposits Events' y" Net Deposits Mart', el equipo de Risk es "Fraud Signals", Games es "Bet Events' y" Leaderboards ", y la plataforma central proporciona un catálogo, esquemas de contratos, accesos, monitoreo de calidad, phinops y herramientas de streaming/ELT.

1) Principios de Data Mesh

1. Responsabilidad de dominio: cada dominio (Payments, Risk, Games, KYC/Compliance, CRM, Affiliate) posee sus conjuntos de datos y su ciclo de vida.
2. Datos como producto: cada conjunto tiene un propietario, descripción, SLO, acceso SLA, documentación, versión, retroalimentación y hoja de ruta.
3. Plataforma de autoservicio: pipelines estándar ingest/transformación/serve, plantillas, seguridad predeterminada, directorio y observabilidad.
4. Gestión federada: normas comunes de esquemas, métricas, PII/localización y calidad - en el centro; implementación y evolución - en los dominios.

2) Modelo operativo y roles

Domain Data Product Owner (DPO): priorización, SLO, backlog de mejoras de productos de datos.
Domain Data Engineer/Analytics Engineer: circuitos, pipelines, pruebas de DQ, versioning.
Domain Steward: semántica de campos, coincidencia con el diccionario de métricas y la clasificación PII.
Platform Team: catálogo, IAM/RBAC, Policy-as-Code, formatos de tabla (Delta/Iceberg/Hudi), orquestación, observabilidad, phinops.
Federated Governance Board: aprueba estándares (esquemas, métricas, seguridad), resuelve disputas de dominio cruzado.

3) «Data Product» - pasaporte y artefactos

• Contrato (esquema, tipos, evolución, compatibilidad).
• API de acceso (SQL/tabla, topic/stream, archivo/share).
• SLA/SLO (frescura, disponibilidad, calidad).
• Pruebas DQ (singularidad, rangos, integridad referencial).
• Documentación (descripción de campos, consultas de ejemplo, owner, contacto).
• Versioning (versionar esquemas semánticos, política de depreciación).
• Directivas (PII, localización, retention/TTL, derechos).

Plantilla de pasaporte (YAML, ejemplo)

yaml name: bets. events. v1 domain: games owner: games-data@company interface:
sql: lakehouse. silver. bets_events stream: kafka://bets. events. v1 share: read-only (EU only)
schema_version: 1. 3. 0 slo:
freshness: "<= 5 min (p95)"
availability: ">= 99. 9%"
dq:
- unique: bet_id
- valid_values: currency in [EUR, USD, TRY, BRL]
- non_negative: [stake, payout]
security:
pii: false region: EU retention: 365d lineage:
sources: [game_engine. outbox, payments. psp. webhooks]
consumers: [crm. triggers, risk. realtime, dwh. fact_bets]
versioning:
compat: backward deprecation_policy: "60 days"

4) Interoperabilidad y estándares

Esquemas/Contratos: Avro/Protobuf/JSON-Schema + Registro Schema; política de back-compat, prohibición de romper cambios sin una nueva versión mayor.
Capa semántica: definiciones uniformes de GGR, NGR, Depósitos Net, LTV, cohortes - como código (dbt metrics/semantic layer).
Identificadores: global 'player _ id', 'tenant _ id', 'bet _ id', referencias unificadas de países/monedas/proveedores.
Metadatos: columnas obligatorias 'ingest _ ts',' schema _ version ',' trace _ id ',' source ',' region '.
Acceso: SQL (lakehouse/OLAP), stream (Kafka/Pulsar), tablas de sharing/snapshots; el formato de intercambio es Parquet/Delta/Iceberg.

5) Referencia tecnológica (agnósticamente a los vendedores)

Ingest: Outbox/CDC из OLTP → Kafka → Lakehouse (Bronze).
Transform: ELT/dbt в Silver/Gold; incrementales 'MERGE', SCD, escaparates materiales.
Serve: OLAP (ClickHouse/BigQuery/Snowflake), RT-движки (Pinot/Druid) для near-real-time.
Directorio/Lineage: directorio único, documentación automática, gráfico de dependencias.
Observabilidad: métricas de frescura/SLO, DQ-assert, lags de streaming, costo.
Políticas: IAM/RBAC/ABAC, cifrado, localización (enrutamiento de datos de zona).

6) SLO/SLA para productos de datos

• Freshness: Bets Events (p95) ≤ 5 мин; Señales de Fraud ≤ 30 segundos; Net Deposits Mart ≤ 15 minutos.
• Availability: ≥ 99. 9% para interfaces de lectura.
• Calidad: duplicados ≤ 0. 01%, proporción de campos obligatorios vacíos ≤ 0. 1%, consistencia de divisas 100%.
• Costo SLO: costo de escáneres de escaparate ≤ N $/día, pequeños archivos ratio <10%.

7) Seguridad, PII y localización

Clasificación: PII/finados/operativos sensibles.
Techmers: encriptación at-nat/in-transit; tokenización PII; enmascarar columnas; filtros row-level por 'tenant _ id'.
Localización: los productos de dominio se publican en regiones autorizadas (EU/TR/LATAM); sharing transfronterizo - sólo unidades sin PII.
Auditoría: quién publicó/leyó; versión del diagrama; Solicitudes de escalamiento de derechos - a través de la negociación.

8) FinOps y gestión de costos

Presupuestos por dominios: límites de computación, alertas de sobrecostos.
Almacenamiento: clases de almacenamiento + TTL (Bronze corto, Plata medio, Oro largo/unidades).
Optimización de consultas: lotes/clústeres, vistas materializadas, caché de resultados de BI.
Archivos pequeños: compactación/políticas OPTIMIZE; tamaño de archivo objetivo 128-1024 MB.

9) Ciclo de vida y evolución

Versioning: 'domain. product. v{major}`; campos menores - back-compat.
Deprechate: aviso de los consumidores, período «de dos carriles», alertas automáticas en versiones antiguas.
Cambios en los esquemas: Pull Request en el repositorio de contratos; Pruebas de compatibilidad CI; Publicación automática en el directorio.
Retroalimentación: canal del producto (issue tracker), NPS de los consumidores, tiempo de respuesta a incidentes.

10) Especificación para iGaming - Mapa de dominios y productos

Payments

`payments. psp. webhooks. v1` (stream)

`mart_net_deposits_daily. v1 '(SQL) - SLO de frescura ≤ 15 min; PII-free

Games

`bets. events. v1 '(stream/SQL) - p95 ≤ 5 min

`mart_ggr_daily. v1 '(SQL/MV) - agregados por país/juego

Risk/Anti-fraud

`risk. signals. v1 '(stream) - p95 ≤ 30 segundos

`risk. case_mgmt. v1 '(SQL) - SCD2 de la historia de las investigaciones

CRM/Personalization

`crm. triggers. v1 '(stream) - disparadores segmentarios

`profile. features. online. v1 '(KV/SQL) - fichi en línea (TTL)

KYC/Compliance

`kyc. status. v1 '(SQL) - PII protegido, row-level policies

`responsible_gaming. events. v1 '(stream) - límites/señales

11) Procesos y artefactos de la plataforma

Directorio: buscar por dominio/campo/PII etiquetas, previsualizar esquemas y ejemplos.
Generadores de plantillas: cookiecutter para el nuevo producto (pasaporte, CI, pruebas DQ, dashboard SLO).
Policy-as-Code: reglas de exportación, PII, sharinga entre regiones.
Observabilidad: dashboards terminados: Freshness, DQ-bugs, Costo, Lineage, Stream lag.
Runbooks: incidentes de frescura/DQ/circuitos, deprechate de emergencia, reversión de versiones.

12) Migración a Data Mesh (hoja de ruta)

1. Inventario de datasets actuales → agrupación por dominios.
2. Piloto de 2-3 dominios (Payments, Games, Risk) - formalizar como productos con pasaportes.
3. Catálogo y estándares: esquemas, métricas, PII/localización, DQ.
4. Self-serve: plantillas de pipeline, CI/CD, monitoreo de SLO.
5. Corte de escaparates monolíticos en dominios; Soporte de dos rieles para interfaces antiguas.
6. El Consejo Federal es las sesiones ordinarias, el rugido del contrato de cambios.
7. Escalar en CRM/Afiliados/Marketing, luego en shers de afiliados.

13) Lista de verificación de implementación

Dominios definidos; propietarios y canales de comunicación asignados.
El directorio se está ejecutando; pasaporte de cada producto publicado.
Esquemas: en el repositorio de contratos; CI prueba la compatibilidad/DQ.
SLO/SLA declarados; dashboards Freshness/DQ/Cost están disponibles.
Políticas PII/localización - código; auditoría habilitada.
FinOps: presupuestos, alertas, informe de «costo por dominio».
Proceso de versionamiento/depreciación: documentado y automatizado.
Incidentes de Runbooks: disponibles y revisados (game-day).

14) Antipattern

«Rebautizado como Data Mesh, pero todo a través del equipo central de datos» - el cuello estrecho no se elimina.
La ausencia de un diccionario único de métricas → GGR/NGR difiere entre dominios.
Los esquemas sin contratos y pruebas de compatibilidad → lanzamientos «rompedores».
No hay autoservicio → cada tabla se crea manualmente, tiempo alto a datos.
Ignorar el PII/localización en la intersección regional.
Microproductos sin propietarios/SLO - datos «abandonados».

15) KPI del éxito de Data Mesh

Time-to-Data: desde la idea hasta el producto de datos disponible (mediana de ↓).
Reutilización: número de dominios consumidores por producto.
Calidad: proporción de verificaciones DQ exitosas, defectos en millones de eventos.
Fiabilidad: cumplimiento de SLO frescura/disponibilidad.
Costo: $/consulta/usuario, cuota de archivos pequeños, eliminación por computadora.
Velocidad de cambio: lanzamientos de diagramas/escaparates por semana.

Data Mesh no es sólo una tecnología, sino también una federación de dominios administrados donde los datos son productos con sus propietarios, SLO, contratos y métricas de calidad. En iGaming, este enfoque elimina las gargantas estrechas, acelera las integraciones (antifraude, pagos, CRM), mejora la transparencia de las métricas (GGR/NGR/LTV) y controla el costo. Construye una fuerte plataforma de autoservicio, introduce estándares federados y una cultura de «datos como producto», y tu ecosistema analítico se escala junto con el negocio, sin perder calidad, velocidad y cumplimiento.