Data Mesh: modelo de dados federado

(Secção Tecnologia e Infraestrutura)

Resumo curto

O Data Mesh é um modelo organizacional e técnico, onde os dados são considerados produtos de comandos de domínios, e o papel central da plataforma é fornecer autoatendimento, padrões e complicações. Para iGaming, isso significa que a equipe de Payments possui o Deposit Events e o Net Depositits Mart, a equipe de Risk é a Fraud Signals, a Games é a Bet Events e a plataforma central fornece o catálogo, os contratos de circuito, a disponibilidade, o monitoramento de qualidade, os finops e a plataforma central ferramentas de streaming/ELT.

1) Princípios do Data Mesh

1. Domínio: Cada domínio (Payments, Risk, Games, KYC/Compliance, CRM, Affiliate) possui seus conjuntos de dados e seu ciclo de vida.
2. Dados como produto: cada conjunto tem dono, descrição, SLO, acesso SLA, documentação, versão, feedback e cartão de trânsito.
3. Plataforma Self-serve: pipline padrão ingest/trans/serve, modelos, segurança padrão, diretório e observabilidade.
4. Gerenciamento federal: padrões gerais de esquema, métricas, PII/localização e qualidade - no centro; implementação e evolução - em domínios.

2) Modelo operacional e papéis

Domain Data Product Owner (DPO): priorização, SLO, backlogs de melhorias no produto de dados.
Domain Data Engineer/Analytics Engineer: circuitos, piplines, testes de DQ, versioning.
Domain Steward: semântica de campos, conformidade com dicionário de métricas e classificação PII.
Plataforma Team: catálogo, IAM/RBAC, Policy-as-Code, formatos de tabela (Delta/Iceberg/Hudi), orquestração, observabilidade, finopes.
Federated Governance Board: aprova padrões (esquemas, métricas, segurança) e resolve disputas de domínios cruzados.

3) «Data Product» - passaporte e artefatos

• Contract (padrão, tipos, evolução, compatibilidade).
• API de acesso (SQL/tabela, topic/stream, arquivo/share).
• SLA/SLO (frescura, disponibilidade, qualidade).
• Testes DQ (exclusividade, faixas, integridade de referência).
• Documentação (descrição de campos, exemplos de solicitação, owner, contato).
• Versioning (semantic versioning circuitos, política de depredação).
• Políticas (PII, localização, retenção/TTL, direitos).

Modelo de passaporte (YAML, exemplo)

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) Interoperabilidade e padrões

Esquemas/contratos: Avro/Protobuf/JSON-Schema + Schema Registry; política de back-compat que impede alterações de quebra sem uma nova versão maior.
Camada semântica: Definições de GGR, NGR, Net Depositits, LTV, cômodos - como código (dbt metrics/semantic layer).
Identificadores: globais 'player _ id', 'tenant _ id', 'bet _ id', guias unificados de países/moedas/provedores.
Metadados: colunas obrigatórias 'ingest _ ts', 'schema _ versão', 'trace _ id', 'fonte', 'region'.
Acesso: SQL (lakehouse/OLAP), estirpe (Kafka/Pulsar), tabelas de sharing/snapshots; Formato de troca - Parquet/Delta/Iceberg.

5) Referência tecnológica (agnóstico para vendedores)

Ingest: Outbox/CDC из OLTP → Kafka → Lakehouse (Bronze).
Transform: ELT/dbt в Silver/Gold; «MERGE», SCD, vitrines materiais.
Serve: OLAP (ClickHouse/BigQuery/Snowflake), RT-движки (Pinot/Druid) для near-real-time.
Catálogo/Lineage: diretório único, documentação automática, gráfico de dependências.
Observabilidade: métricas de frescura/SLO, DQ-assert, lajes de strim, custo.
Políticas: IAM/RBAC/ABAC, criptografia, localização (rotação de dados de área).

6) SLO/SLA para produtos de dados

• Freshness: Bets Events (p95) ≤ 5 мин; Fraud Signals ≤ 30 segundos; Net Deposits Mart ≤ 15 min
• Availability: ≥ 99. 9% para interfaces de leitura.
• Quality: Duplicado ≤ 0. 01%, percentual de campos obrigatórios vazios ≤ 0. 1%, 100% de consistência cambial.
• Costa SLO: Valor das raias de vitrine ≤ N $/dia, small files ratio <10%.

7) Segurança, PII e localização

Classificação PII/sensíveis de final/operação.
Técnicas: criptografia at-rest/in-transit; toquenização PII; camuflar colunas; filtros row-level por 'tenant _ id'.
Localização: Produtos de domínio são publicados em regiões permitidas (EU/TR/LATAM); Sharing de fronteira - apenas unidades sem PII.
Auditoria: quem publicou/leu; versão do esquema; solicitação de habilitação por meio de concordata.

8) FinOps e gerenciamento de custo

Orçamentos de domínios: limites de compute, alertas de sobrepreço.
Armazenamento: Classes de armazenamento + TTL (Bronze curto, Silver médio, Gold longo/unidade).
Otimização de solicitações: partitações/clusterização, visualizações materializadas, BI.
Small files: competition/OPTIMIZE políticas; tamanho alvo do arquivo 128-1024 MB.

9) Ciclo de vida e evolução

Versioning: 'domain. product. v{major}`; campos menores - back-compat.
Deprekate: notificação dos consumidores, período de dois caminhos, alertas automáticas para versões antigas.
Mudanças de esquema: Pull Request para o repositório de contratos; Testes de compatibilidade CI; a publicação automática para o catálogo.
Feedback: canal do produto (issue tracker), NPS dos consumidores, hora para responder aos incidentes.

10) Especificação para iGaming - mapa de domínios e produtos

Payments

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

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

Games

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

`mart_ggr_daily. v1 '(SQL/MV) - unidades por país/jogo

Risk/Anti-fraud

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

`risk. case_mgmt. v1 '(SQL) - SCD2 histórico de investigação

CRM/Personalization

`crm. triggers. v1 '(stream) - desencadeadores segmentais

`profile. features. online. v1 '(KV/SQL) - fici online (TTL)

KYC/Compliance

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

`responsible_gaming. events. v1 '(stream) - limites/sinais

11) Processos e artefatos da plataforma

Catálogo: pesquisa de domínio/campo/rótulos PII, pré-visualização de esquemas e exemplos.
Geradores de modelos: cookiecutter para o novo produto (passaporte, CI, testes DQ, dashboard SLO).
Policy-as-Código: regras de exportação, PII, sharing entre regiões.
Observabilidade: dashboards prontos: Freshness, DQ Erros, Cost, Lineage, Stream lag.
Runbooks: incidentes de frescura/DQ/circuitos, deprekate de emergência, reversão de versões.

12) Migração para o Data Mesh (mapa de trânsito)

1. Inventário de datasets atuais → agrupamento por domínio.
2. Piloto de 2-3 domínio (Payments, Games, Risk) - confeccionar como produtos com passaportes.
3. Diretório e padrões: esquemas, métricas, PII/localização, DQ.
4. Self-serve: modelos de pipline, CI/CD, monitoramento SLO.
5. Corte de vitrines monolíticas para domínios; suporte de dois caminhos para interfaces antigas.
6. Conselho Federal - sessões regulares, revezamento do contrato de mudanças.
7. Escala em CRM/Afiliados/Marketing, depois em parceiras.

13) Folha de cheque de implementação

Domínios definidos; proprietários e canais de comunicação são designados.
Catálogo executado; passaporte de cada produto publicado.
Esquemas - no repositório de contratos; A CI está testando compatibilidade/DQ.
Os SLO/SLA foram declarados; Os dashboards Freshness/DQ/Costa estão disponíveis.
Políticas PII/localização - código; a auditoria está ativada.
FinOps, orçamentos, alertas, «valor de domínio».
Processo de versionização/depósito - documentado e automatizado.
Incidentes de runbooks - disponíveis e treinados (game-day).

14) Antipattern

"Renomeado para Data Mesh, mas tudo através do comando central de dados - a garganta estreita não é eliminada.
A ausência de um único dicionário de métricas GGR/NGR varia entre os domínios.
Esquemas sem contratos ou testes de compatibilidade → lançamentos «quebrantes».
Sem Self-serve → cada tabela é criada manualmente, com time-to-data alto.
Ignorar PII/localização em sharing cruzado-regional.
Os micro-produtos sem proprietários/SLO são dados «abandonados».

15) KPI de sucesso Data Mesh

Time-to-Data: desde a ideia até o produto de dados disponível (mediana ↓).
Reutilização: número de domínios de consumo por produto.
Qualidade: Taxa de verificação DQ bem sucedida, defeitos em milhões de eventos.
Confiabilidade: conformidade SLO recente/disponibilidade.
Custo: $/consulta/usuário, participação small files, reciclagem compute.
Velocidade de alterações: lançamentos de circuito/vitrines por semana.

Resumo

O Data Mesh não é apenas uma tecnologia, mas também uma federação de domínios administrada, onde os dados são produtos com seus proprietários, SLO, contratos e métricas de qualidade. Em iGaming, essa abordagem alivia gargalos estreitos, acelera a integração (antifrode, pagamentos, CRM), melhora a transparência das métricas (GGR/NGR/LTV) e controla o custo. Construa uma forte plataforma self-serve, introduza padrões federativos e uma cultura de «dados como produto», e seu ecossistema analítico é escalado com o negócio - sem perda de qualidade, velocidade e complacência.