Como a Monzo estrutura engenharia para fazer centenas de deploys por dia sem quebrar a confiança

Suhail Patel é staff engineer no grupo de plataforma da Monzo, o banco digital britânico sem agências físicas, com 14 milhões de clientes e expansão em curso para Europa e Estados Unidos. Em uma apresentação na QCon London registrada pelo InfoQ, ele descreve como a empresa chegou a mais de 3.000 microsserviços em produção, mantidos por apenas algumas centenas de engenheiros, publicando mudanças centenas de vezes por dia.

O ponto de partida do argumento de Patel é uma crítica a um modelo comum em empresas reguladas: comitês de aprovação de mudança, formados por áreas de risco, compliance, plataforma e segurança, que podem travar ou atrasar qualquer release. Segundo ele, esses fóruns surgem porque certas mudanças têm raio de impacto grande demais para a confiança da organização, e a equação de risco vira mais mental do que técnica. A alternativa que a Monzo escolheu não foi eliminar o controle, e sim embuti-lo na plataforma.

A aposta de 2016 que sustenta tudo hoje

Monzo fez, em 2016, o que Patel chama de "innovation tokens" bem gastos: apostar em Go, Kubernetes↳Kubernetes18 conteúdosGerenciamento de infraestrutura multicloud com Kubernetes proporciona otimização e economiaDevSecOps · set 2021Azure Kubernetes Services – AKS: referências gratuitas e dicas para solução de problemas comunsDevSecOps · abr 2019Kubernetes em produção: o que ninguém te conta e você aprende tarde demaisDev (Back & Front) · abr 2026Ver tudo em DevSecOps → e uma arquitetura de microsserviços como fundação. Desde então, a empresa foi deliberada ao adicionar tecnologia nova, sempre encapsulando os componentes de plataforma atrás de bibliotecas próprias em vez de expor Kubernetes, Kafka ou os detalhes de infraestrutura diretamente ao engenheiro de produto.

Em resumo: o time de plataforma não entrega ferramentas soltas, entrega abstrações opinativas e testadas, com telemetria embutida por padrão em cada serviço, independentemente de ele atender uma requisição por segundo ou um milhão.

Anatomia de um microsserviço: tudo pelo mesmo molde

A Monzo mantém um monorepo com um gerador de bootstrap que cria a mesma estrutura de pastas para todo microsserviço novo. Isso elimina parte da carga cognitiva de navegar em um código desconhecido:

• Lógica de banco de dados↳Banco de dados134 conteúdosSQL ou NoSQL: eis a questão!!Data · mar 2020Banco de dados: como organizar e dar segurança para milhões de dados de loteriasData · mai 20215 serviços gratuitos na cloud para bancos de dados PostgresData · fev 2025Ver tudo em Data → sempre na pasta dao
• Consumo de fila sempre na pasta consumer
• Camada de RPC sempre na pasta handler

Todo engenheiro, veterano ou recém-chegado, sabe onde procurar. A maior parte dos serviços é escrita em Go, e o time de plataforma embute boas práticas de segurança diretamente nas bibliotecas compartilhadas, em vez de depender de revisão manual repetida a cada novo serviço.

Arquivos proto como contrato único

O fluxo de criação de um serviço começa com a definição de um arquivo proto contendo o contrato da API. Geradores internos compilam esse arquivo em código Go que já embute as bibliotecas de HTTP e a telemetria padrão da casa, incluindo validação além dos tipos nativos do protobuf. O mesmo mecanismo é usado para gerar lógica de consumo e produção de eventos em filas Kafka: o engenheiro define o payload e as regras de validação, e a Monzo gera o código de transporte.

O ganho prático, segundo Patel, aparece quando o time de infraestrutura ou segurança precisa corrigir um bug ou aplicar uma melhoria de performance: a correção entra na biblioteca geradora e se propaga para os mais de 3.000 serviços ao regenerar os stubs, sem depender de que cada squad atualize seu código manualmente.

O "paved path" em vez do comitê de mudança

A tese central da palestra é que governança eficaz não vem de aprovar mudanças uma a uma, vem de tornar o caminho certo o caminho mais fácil. Patel descreve um guia estruturado de onboarding, o "backend 101", que ensina as ferramentas, as convenções de escrita de Go e a arquitetura de microsserviços logo na entrada do engenheiro na empresa, conhecimento que, segundo ele, permanece útil durante toda a carreira ali dentro.

Ninguém acorda de manhã e instrui o agente a escrever código ruim, assim como um humano não acorda um dia querendo escrever código ruim.

Nobody wakes up in the morning and instructs their agent to go and write bad code, just like a human doesn't wake up one day to write bad code.Suhail Patel, staff engineer no Core Platform da Monzo

No resumo oficial da apresentação, o InfoQ cita outras peças desse arcabouço de confiança que sustentam a velocidade de entrega: abstrações opinativas de microsserviço, ambientes de staging organizados por tenancy, checagens estáticas de código e profiling contínuo em produção. A ideia comum entre elas é detectar desvio de comportamento antes que ele vire incidente, em vez de impedir a mudança antes que ela aconteça.

IA sem alucinar: documentação virou "skill"

A parte mais atual do argumento de Patel conecta esse investimento em padronização ao uso de ferramentas como Claude e Cursor dentro da Monzo. Como toda a documentação de onboarding e as convenções de código já estavam escritas e padronizadas para humanos, o time conseguiu transformar esse material em contexto estruturado para agentes de IA↳Agentes de IA42 conteúdosOpera passa a integrar ChatGPT, Claude e outros agentes de IADev (Back & Front) · mar 2026Operações mais inteligentes, decisões mais rápidas: o impacto da IA agêntica na rotina de TIAI · abr 2026Adobe aposta em orquestração de agentes de IA: o que muda para devsDev (Back & Front) · abr 2026Ver tudo em AI →, em vez de deixá-los adivinhar a estrutura de um serviço.

Com mais de 3.000 exemplos reais de serviços no mesmo monorepo, seguindo a mesma convenção de pastas e o mesmo gerador de proto, as ferramentas de IA têm referência concreta para seguir, e não apenas o conhecimento genérico de treinamento. Patel argumenta que isso reduz a chance de o agente inventar um pacote de serviço que não existe ou quebrar o padrão da casa.

Ele também usa o caso amplamente divulgado de uma reportagem do Financial Times que atribuiu falhas de confiabilidade na Amazon a mudanças assistidas por IA, episódio que levou a Amazon a publicar uma retratação pública corrigindo que as mudanças exigiam aprovação de engenheiro sênior, não que fossem automaticamente geradas por IA. Para Patel, o detalhe de quem (humano ou agente) escreveu a mudança importa menos do que o objetivo compartilhado: não quebrar a confiança do sistema.

O que isso muda para quem constrói aqui

Poucas empresas no Brasil vão operar na escala de 3.000 microsserviços, mas o raciocínio da Monzo vale para squads de plataforma de qualquer tamanho: um gerador de boilerplate que cria sempre a mesma estrutura de pastas custa pouco para implementar e paga dividendos a cada engenheiro novo que entra no time. O mesmo vale para contratos de API centralizados em proto (ou OpenAPI, para quem trabalha com REST), que permitem propagar correções de segurança sem depender de que cada squad lembre de atualizar manualmente.

O ponto mais relevante para quem já está testando Claude, Cursor ou Copilot em produção é a lição sobre contexto: um agente de código rende mais quando aponta para uma base de exemplos reais e convenções documentadas do que quando opera sobre um conjunto heterogêneo de serviços, cada um com sua própria estrutura. Fintechs e bancos digitais brasileiros que já lidam com exigência regulatória semelhante à de Monzo no Reino Unido tendem a encontrar na padronização de plataforma, mais do que em comitês de aprovação, o caminho para manter a velocidade de entrega sem perder a confiabilidade esperada de um sistema financeiro.

Fonte: InfoQ