Data mesh é uma abordagem de arquitetura de dados que distribui a propriedade e a responsabilidade pelos dados entre os times de negócio que os geram, em vez de concentrar tudo em uma equipe central de dados. Proposta por Zhamak Dehghani em 2019, a ideia central é tratar cada domínio de negócio — vendas, logística, produto — como dono de seus próprios “produtos de dados”, publicados e consumidos por outras áreas através de padrões e uma plataforma comuns, com governança compartilhada entre os domínios.
O que é data mesh
Em arquiteturas tradicionais de dados, um time central de engenharia de dados é responsável por ingerir, transformar e disponibilizar dados de toda a empresa, normalmente através de um data lake ou data warehouse único. Conforme a organização cresce, esse time central se torna um gargalo: qualquer mudança de esquema, nova fonte de dados ou solicitação de relatório passa por uma fila compartilhada entre todas as áreas da empresa. O data mesh propõe inverter essa lógica, aplicando à área de dados o mesmo princípio que a arquitetura de microsserviços aplicou ao desenvolvimento de software: descentralizar a responsabilidade técnica, mantendo padrões e governança comuns para que as partes continuem interoperáveis.
Os quatro princípios do data mesh
O primeiro princípio é a propriedade orientada a domínio (domain ownership): cada área de negócio que gera ou melhor entende um conjunto de dados é responsável por modelá-lo, mantê-lo e disponibilizá-lo, em vez de repassar essa responsabilidade a um time central que não tem o contexto de negócio necessário. O segundo é dado como produto (data as a product): cada domínio trata os dados que expõe como um produto de verdade, com documentação, SLA de qualidade e atualização, contrato de schema estável e um “dono” responsável por atender às necessidades de quem consome esse dado. O terceiro é a plataforma self-service (self-serve data platform): uma infraestrutura comum, mantida por um time de plataforma, que abstrai a complexidade de armazenamento, processamento e catalogação, permitindo que os times de domínio publiquem e consumam dados sem precisar reinventar ferramentas próprias. O quarto é a governança federada computacional (federated computational governance): as regras de segurança, qualidade, conformidade e interoperabilidade são definidas de forma colaborativa entre os domínios, mas aplicadas automaticamente pela plataforma — como políticas de acesso, padrões de nomenclatura e requisitos de qualidade embutidos no próprio pipeline, não fiscalizados manualmente por um time central.
Data mesh vs. data lake ou data warehouse centralizado
A diferença central não é tecnológica, mas organizacional: um data lake ou data warehouse centralizado pode perfeitamente hospedar uma implementação de data mesh por baixo dos panos, já que data mesh é um modelo de arquitetura e de organização de times, não uma ferramenta específica. Em um modelo centralizado clássico, um único time de dados é responsável fim a fim por ingestão, modelagem e disponibilização de todos os dados da empresa, o que simplifica a governança mas cria dependência e filas de trabalho. No data mesh, cada domínio publica seus próprios produtos de dados na plataforma comum, o que distribui a carga de trabalho e aproxima quem modela o dado de quem entende seu significado de negócio, ao custo de exigir mais maturidade organizacional, padronização técnica e disciplina de governança para que os domínios continuem interoperáveis entre si.
Quando data mesh faz sentido
Data mesh tende a compensar em organizações grandes, com múltiplos domínios de negócio distintos, dezenas de fontes de dados e um time central de dados que já se tornou um gargalo reconhecido pela empresa. Também faz mais sentido onde já existe alguma maturidade em engenharia de software e cultura de produto, porque tratar “dado como produto” exige práticas como versionamento de schema, documentação e SLA que boa parte das equipes de dados ainda não pratica. Para empresas menores, ou que ainda estão construindo sua primeira base de dados analítica confiável, um data lake ou data warehouse centralizado, bem modelado e governado, costuma ser a escolha mais pragmática — a complexidade organizacional do data mesh só se paga quando o gargalo central já é um problema real e recorrente, não um risco hipotético.
O papel da BlueMetrics
A BlueMetrics avalia, para cada cliente, se a arquitetura de dados ideal é um data warehouse ou lakehouse centralizado, um modelo híbrido, ou uma abordagem inspirada em data mesh — sempre com base no tamanho da organização, na maturidade dos times e no volume real de domínios de dados envolvidos. Com mais de 200 projetos de dados e IA aplicada entregues, a experiência mostra que a arquitetura certa é a que reduz atrito e sustenta governança de dados sólida, não necessariamente a mais recente ou mais discutida no mercado.