Data Mesh

O modelo centralizado de dados — uma equipe de engenharia de dados responsável por integrar, transformar e disponibilizar dados de toda a organização — funcionou bem quando as organizações tinham poucos sistemas e os casos de uso eram relativamente previsíveis. Com o crescimento da complexidade digital, esse modelo começou a produzir gargalos sistemáticos: a equipe central não conseguia atender a demanda de todos os domínios, o conhecimento de contexto de negócio ficava diluído, e dados de qualidade ruim chegavam ao time de analytics porque a equipe de engenharia não tinha o contexto de domínio para validá-los adequadamente.

Data Mesh é uma abordagem arquitetural e organizacional para gestão de dados em escala, proposta por Zhamak Dehghani em 2019, que trata dados como produto e distribui a responsabilidade pelos dados para os domínios de negócio que os geram — em vez de centralizá-la em uma equipe de plataforma de dados. É uma inversão do paradigma: em vez de dados fluírem para um repositório central gerido por especialistas técnicos, cada domínio é responsável por seus dados como produto acessível a consumidores internos.

Data Mesh não é uma tecnologia — é um conjunto de princípios organizacionais. A implementação técnica varia; os princípios são invariantes.

1. Propriedade de dados orientada a domínio (Domain-Oriented Ownership): os dados pertencem e são geridos pelos domínios de negócio que os geram. O time de vendas é responsável pelos dados de pedidos; o time de marketing pelos dados de campanhas; o time de produto pelos dados de comportamento de usuário. Esse time tem o contexto de domínio necessário para garantir qualidade, documentação e semântica correta.

2. Dados como produto (Data as a Product): cada domínio disponibiliza seus dados como produto para consumidores internos — com a mesma qualidade, documentação, SLA e facilidade de descoberta que um produto de software externo. Critérios de qualidade de um data product: descobrível (está no catálogo com documentação), endereçável (tem identificador estável), confiável (tem SLA de qualidade e atualização), self-describing (schema e semântica documentados), interoperável (padrões comuns), seguro (controles de acesso apropriados).

3. Plataforma de dados de self-service (Self-Serve Data Platform): uma plataforma central provê a infraestrutura que os domínios precisam para criar e gerenciar seus data products sem precisar de expertise de infraestrutura — storage, compute, catalogação, monitoramento, controle de acesso. A plataforma elimina o overhead técnico para que os domínios possam focar no domínio.

4. Governança federada com interoperabilidade (Federated Computational Governance): cada domínio tem autonomia sobre seus dados, mas dentro de standards comuns definidos centralmente — formatos de dados interoperáveis, classificação de dados pessoais, padrões de segurança, métricas de qualidade mínimas. A governança é computacional quando possível — políticas aplicadas automaticamente pela plataforma, não por revisão manual.

O contexto que torna Data Mesh relevante é o de organizações com múltiplos times de produto, domínios de negócio distintos e casos de uso analítico diversificados.

O problema do time central de dados: em uma organização grande, um time central de engenharia de dados se torna gargalo — não consegue absorver toda a demanda de integração e transformação. Prioriza o que consegue, deixando domínios sem dados adequados. Torna-se, na prática, um time de manutenção de pipelines em vez de habilitador de valor analítico.

O problema da perda de contexto: quando engenheiros de dados constroem pipelines para dados do domínio de vendas sem contexto de vendas, erros de interpretação são inevitáveis. A condição de um pedido "aguardando pagamento" tem nuances que o engenheiro de dados central desconhece — mas o time de vendas sabe exatamente.

O problema de escala: à medida que novos domínios de produto emergem, o modelo centralizado não escala. Data Mesh distribui a responsabilidade para escalar com a organização.

Data Mesh não é a resposta universal. É uma solução para problemas específicos de escala e organização.

Data Mesh faz sentido quando:

• A organização tem múltiplos domínios de negócio distintos com times de produto autônomos
• O time central de dados é um gargalo crônico para demandas analíticas
• Diferentes domínios têm casos de uso tão distintos que centralização gera mais atrito do que valor
• Há maturidade organizacional para que os domínios assumam responsabilidade por dados como produto

Abordagem centralizada faz sentido quando:

• A organização é relativamente pequena com poucos domínios
• Não há times de produto autônomos por domínio com engenheiros dedicados
• Os casos de uso analíticos são principalmente cross-domain e exigem integração central
• A organização está ainda construindo maturidade de dados básica

O erro mais comum: adotar Data Mesh em organizações que ainda não têm os fundamentos de dados no lugar (data warehouse confiável, ETL funcional, práticas básicas de data quality). Data Mesh pressupõe maturidade — não é o ponto de partida.

Implementar Data Mesh não é comprar uma ferramenta — é mudar a forma como times são organizados e responsabilizados.

Mudança organizacional: times de produto passam a incluir responsabilidade pelos seus data products. Engenheiros de dados ficam embarcados em times de domínio, não concentrados em time central. É uma mudança de reporting e de accountability, não apenas de processo.

Mudança técnica: cada domínio precisa de capacidade de criar e gerenciar pipelines de dados, expor interfaces de dados com SLA definido, monitorar qualidade dos seus data products. A plataforma central provê as ferramentas para isso — mas o trabalho é do domínio.

Mudança de governança: standards comuns precisam ser definidos e aplicados. Formato de identificadores de entidade (como um "cliente" é referenciado consistentemente entre domínios?), classificação de dados pessoais, padrões de qualidade mínimos para publicação de data product.

Data Mesh é um dos conceitos de dados com mais hype e mais mal compreendidos dos últimos anos. A ideia é genuinamente relevante para organizações com os problemas que resolve — mas é frequentemente vendida como solução universal quando é uma solução específica para problemas de escala e gargalo organizacional que a maioria das PMEs simplesmente não tem.

Para empresas de médio porte, o diagnóstico honesto antes de considerar Data Mesh: existe um time central de dados que é gargalo crônico? Os domínios de negócio têm times com capacidade técnica para assumir responsabilidade por dados como produto? Se a resposta for não para qualquer uma dessas perguntas, Data Mesh é solução para o problema errado — e a energia deve ir para construir os fundamentos de dados que ainda faltam.

Quando a organização crescer ao ponto onde esses problemas são reais, Data Mesh vai fazer sentido naturalmente. Adotá-lo prematuramente adiciona complexidade organizacional sem os benefícios que justificam essa complexidade.