O neobank britanico Monzo descreveu publicamente como roda uma operacao de dados com 100 times de produto e mais de 12 mil modelos dbt sem que isso vire um pesadelo operacional. A receita e uma versao adaptada do data mesh que a empresa chama de “meshy”. Os numeros reportados sao 40% a menos em custos de data warehouse e 25% a mais em velocidade de entrega.

O que “meshy” significa na pratica

Data mesh (arquitetura de dados que distribui a propriedade dos pipelines entre os times de produto em vez de concentrar tudo em uma equipe central de dados) e um conceito que costuma ser aplicado de forma rigida em conferencia e de forma fluida na realidade. O Monzo decidiu nomear sua adaptacao com um termo proprio para deixar claro que nao implementou o data mesh do livro — implementou o que faz sentido para o tamanho e a cultura da empresa.

O sabor “meshy” combina quatro elementos: dominios de negocio bem definidos como unidade de propriedade, governanca centralizada de regras e padroes, contratos de dados (acordos explicitos entre quem produz e quem consome) e um tooling padrao que todos os times usam.

A combinacao importa mais que cada peca individual. Sem governanca central, voce tem caos federado. Sem autonomia de dominio, voce tem o velho gargalo do time central. Sem contratos, voce tem quebras silenciosas em downstream. Sem tooling padrao, voce tem cada time reinventando pipelines em stacks incompativeis.

Os numeros da operacao

100 times de produto e 12 mil modelos dbt nao e um numero comum em casos publicos de data engineering. Para efeito de escala: e a ordem de grandeza em que faz diferenca se cada modelo dbt e revisado por um humano, por um lint automatico ou por ninguem.

Esse volume so se sustenta porque a propriedade e distribuida. Se um unico time central tivesse que aprovar mudanca em 12 mil modelos, o backlog mataria a empresa. Quando cada dominio cuida dos seus, a aprovacao acontece local e rapido.

O Monzo nao detalhou no que era a operacao antes da reorganizacao para meshy. Os comparativos sao todos relativos, sem baseline absoluta publicada.

O que mudou nos custos e na velocidade

Dois numeros reportados pelo Monzo: cerca de 40% de reducao em custos de warehouse e 25% de melhora em velocidade de entrega de dados.

A reducao de custo costuma vir de pelo menos tres lugares quando data mesh funciona: pipelines redundantes que existiam em multiplos times somem porque os contratos eliminam reprocessamento, dominios que nao precisam de dados de alta frequencia rebaixam o tier de armazenamento, e jobs mal otimizados sao revisados pelo proprio time que paga a conta computacional.

A melhora em velocidade vem do gargalo eliminado. Com o time central fora do caminho critico, cada dominio entrega quando estiver pronto, nao quando o backlog do time central permitir.

O Monzo nao quebrou esses 40% e 25% por fonte. Ainda assim, sao numeros de uma empresa que precisa cumprir requisitos regulatorios pesados de banco — nao e um caso de descontrole transformado em vitoria de marketing.

Governanca central + autonomia de dominios

O ponto mais facil de errar em data mesh e o equilibrio entre governanca e autonomia. “Autonomia” sem governanca vira caos federado: cada time escolhe o seu warehouse, o seu transformador, o seu padrao de naming, e as integracoes downstream quebram.

O modelo do Monzo coloca a governanca central no nivel do que precisa ser uniforme — padroes de seguranca, padroes de naming, tooling, ciclo de revisao de contratos — e deixa autonomia no nivel do que pode variar por dominio: schemas internos, frequencia de execucao, cobertura de testes especifica do dominio.

E um modelo federado, no sentido politico do termo. Existe constituicao (governanca central). Existem estados (dominios). Cada estado legisla dentro dos limites da constituicao.

Contratos de dados e tooling padrao como anti-caos

Contratos de dados (data contracts) sao acordos explicitos sobre o que um produtor de dados garante para os consumidores: schema, frequencia, definicao semantica dos campos, SLA. Eles funcionam como uma camada de API entre dominios.

Quando um produtor quer mudar um campo, o contrato obriga ele a avisar antes, oferecer compatibilidade ou negociar a quebra. Em data mesh, isso e o que impede que um time arruine a producao de outro sem saber.

O tooling padrao reforca o contrato. Se todo time usa dbt, a documentacao gerada e o lineage sao homogeneos. Se todo time usa o mesmo orquestrador, monitorar e investigar incidentes funciona com as mesmas ferramentas. O custo de mudar de stack ao longo do tempo aumenta, mas o custo de operar a federacao cai.

O que muda para quem ja usa

Para empresas em crescimento que enfrentam o gargalo de um time central de dados sobrecarregado, o caso do Monzo confirma um padrao que a comunidade ja vinha pintando ha alguns anos: data mesh funciona quando voce trata como problema organizacional, nao como projeto de arquitetura.

A parte tecnica — dbt, warehouses modernos, observabilidade — e relativamente baixa em complexidade comparada a parte organizacional. Distribuir propriedade exige que cada time aceite ser dono dos seus pipelines, dos seus SLAs e dos seus erros. Empresas onde isso e politicamente impossivel nao vao ter sucesso com data mesh, independente do quanto investirem em ferramenta.

O criterio para avaliar a adocao

Se seu time central de dados tem mais de 6 meses de backlog e voce esta considerando meshy ou similar, vale observar tres sinais antes de comecar:

• Existe sponsor executivo disposto a defender a redistribuicao de propriedade quando os times de produto reclamarem que “isso nao e nosso trabalho”?
• Os times de produto ja tem alguem com formacao em dados ou estao todos compostos so de engenheiros de software backend?
• A empresa consegue investir em tooling e governanca antes de ver retorno — sem isso, os tres a seis primeiros meses sao caoticos?

Na leitura do up23labs, e nesse trio que o caso do Monzo se sustenta. Os numeros vieram depois de a empresa ter resolvido essas tres condicoes em ordem, nao em paralelo.

Reportado originalmente por InfoQ em 2026-05-17.