Written by: Nubank Editorial

Em uma palestra apresentada por Katharine Luiza, Engineering Manager no Nubank, durante o 37º Meetup do CNCF, realizado no escritório do Nu, em São Paulo, um tema apareceu repetidamente como peça central da escalabilidade da infraestrutura do Nu: ownership distribuído. 

Ao invés de concentrar responsabilidade operacional em um único time de plataforma, o modelo adotado pelo Nubank transforma infraestrutura em um compromisso compartilhado entre engenharia de produto, automação e governança.

Essa abordagem sustenta uma operação que hoje roda mais de 21 mil databases em produção distribuídos entre Brasil, México e Colômbia. E talvez o mais surpreendente seja que o gerenciamento desse ecossistema é feito por apenas cinco engenheiros diretamente responsáveis pela camada de databases. 

Ainda assim, o ambiente mantém métricas de estabilidade extremamente altas, incluindo mais de seis meses sem crashes de infraestrutura e zero incidentes críticos relacionados a databases nos últimos 12 meses.

Mas o ponto central está na forma como a responsabilidade sobre infraestrutura foi redesenhada para escalar junto com o crescimento da empresa.

O problema real não é provisionar infraestrutura

Criar recursos na nuvem nunca foi exatamente o desafio mais difícil. Afinal, ferramentas de Infrastructure as Code tornaram o provisionamento relativamente simples: qualquer time consegue declarar infraestrutura, abrir um pull request e colocar novos recursos em produção rapidamente.

Porém, à medida que plataformas crescem, databases se multiplicam, produtos evoluem e squads mudam de estrutura, começam a surgir recursos sem contexto claro. Alguns seguem ativos, consumindo capacidade, mas ninguém sabe exatamente para que servem. Outros até possuem algum histórico conhecido, mas já perderam o vínculo com os times que originalmente os criaram. 

Em muitos casos, existe custo operacional e financeiro associado a recursos que ninguém mais monitora ativamente. No Nubank, categorizamos esse cenário em três padrões principais:

  • Os “zumbis” são recursos ativos em produção cujo propósito já não é mais conhecido. Eles continuam rodando, consumindo capacidade e potencialmente armazenando dados importantes, mas ninguém sabe exatamente qual sistema depende deles.
  • Os “órfãos” ainda possuem algum contexto identificável, mas já perderam qualquer ownership claro. Existe uma ideia do que fazem, porém não há um time assumindo responsabilidade sobre eles.
  • E existe ainda uma terceira camada: recursos sem centro de custo claramente associado, o que dificulta a governança financeira e o planejamento de capacidade.

O problema, portanto, era garantir visibilidade contínua sobre o ciclo de vida desses recursos.

Conheça nossas oportunidades

Ownership como parte da arquitetura

A solução começou por uma mudança cultural importante: passamos a exigir ownership para que novas infraestruturas pudessem existir.

No Nubank, qualquer time pode provisionar databases usando infraestrutura declarativa, mas nenhum recurso sobe sem informações obrigatórias de ownership. Obrigatoriamente, todo pull request precisa declarar:

  • o nome do recurso;
  • o time responsável;
  • o owner;
  • e a configuração desejada para aquele ambiente.

Quando ownership deixa de ser uma convenção informal e passa a ser um requisito estrutural do provisionamento, infraestrutura deixa de ser responsabilidade exclusiva do time de plataforma. O time que cria o recurso também se torna responsável por entender como o recurso cresce, quanto ele consome, quais métricas importam e quando ele deveria deixar de existir.

Isso cria um modelo mais sustentável de escalabilidade, porque a responsabilidade operacional é distribuída entre os próprios times de produto.

O papel da plataforma, então, passa a exigir menos operação manual e mais construção de sistemas capazes de automatizar governança, visibilidade e lifecycle management.

Um ecossistema desenhado para automação

Esse modelo funciona porque existe uma camada forte de automação sustentando todo o ciclo de vida da infraestrutura.

Este processo começa em um repositório declarativo chamado Nimbus, no qual os times descrevem os recursos que desejam provisionar.

A partir daí, entra um sistema interno apelidado de “Sorting Hat”. Sua função é decidir automaticamente onde cada recurso deve ser alocado dentro da infraestrutura da empresa.

Essa decisão considera múltiplas regras, como afinidade entre workloads, capacidade disponível, limites de contas, distribuição de recursos, regras corporativas e necessidades futuras de escalabilidade.

Depois da alocação, outro componente chamado Penseira passa a rastrear continuamente esses recursos. Seu papel é manter um inventário vivo da infraestrutura e acompanhar não apenas o que foi declarado, mas o que realmente continua ativo.

Essa distinção se tornou importante porque o time percebeu que “infraestrutura provisionada” e “infraestrutura utilizada” eram coisas completamente diferentes. Nesse contexto, nem todo recurso criado continua exercendo sua função real com o passar do tempo.

Quando lifecycle management vira parte da plataforma

Com ownership distribuído e observabilidade contínua implementados, o próximo passo foi automatizar decisões relacionadas ao ciclo de vida dos recursos.

Foi assim que surgiram sistemas internos voltados especificamente para detecção, arquivamento e remoção segura de bases de dados inativas.

O primeiro deles recebeu o nome de Memento Mori: um sistema que cruza métricas operacionais, dados de inventário, ownership e sinais reais de uso para identificar recursos potencialmente inativos. Ele monitora leitura, escrita, tráfego, operações de entrada e saída de dados e até mesmo mudanças organizacionais nos times responsáveis pelos recursos.

Quando uma database parece abandonada, o sistema começa a notificar automaticamente as pessoas responsáveis via Slack.

O verdadeiro objetivo, porém, é reforçar a responsabilidade operacional. O time responsável recebe contexto, métricas e evidências suficientes para decidir conscientemente o que fazer.

Hoje, a taxa de aprovação de arquivamento desses recursos gira em torno de 89%.

Automatizar remoção exige automatizar segurança

Detectar recursos inativos era apenas metade do problema. A outra metade era garantir que a remoção acontecesse sem risco operacional ou regulatório, e é aqui que entra outro sistema interno: o Reducto.

O processo de remoção envolve muito mais do que simplesmente deletar databases. Como o Nubank opera em múltiplos países e em um ambiente altamente regulado, diferentes regras de retenção precisam ser respeitadas dependendo da localidade e do tipo de produto.

No Brasil, por exemplo, determinados backups precisam permanecer armazenados por até dez anos. Na Colômbia, as exigências são diferentes. E no México, por sua vez, os períodos variam conforme o produto financeiro envolvido.

Quando entra em ação, o Reducto automatiza esse fluxo inteiro, cuidando do:

  • arquivamento;
  • criação de backups;
  • retenção;
  • validação;
  • e remoção segura.

Mesmo depois do arquivamento, existe ainda uma janela de segurança de aproximadamente 35 dias antes da exclusão definitiva do recurso. Isso evita problemas com workloads esporádicos ou sistemas executados em baixa frequência.

Outro ponto crítico é a validação contínua dos backups, porque existe uma premissa importante nesse processo: backup sem restore não é backup. Por isso, os fluxos incluem testes frequentes de recuperação para garantir que os dados realmente possam ser restaurados se necessário.

O resultado é um ciclo altamente automatizado que não abre mão da segurança operacional. Desde a implementação completa desse processo, não registramos incidentes relacionados a remoções automatizadas.

Escalar infraestrutura é escalar responsabilidade

Quando plataformas crescem rapidamente, o desafio passa a ser manter o contexto operacional sobre milhares de componentes distribuídos entre diferentes produtos, times e requisitos regulatórios. Sem visibilidade contínua, ownership claro e lifecycle management consistente, infraestrutura inevitavelmente acumula complexidade invisível.

A combinação entre infraestrutura declarativa, automação e ownership distribuído permitiu que o Nu criasse um ambiente onde milhares de bases de dados podem ser gerenciadas com alto grau de confiabilidade sem depender de burocracia ou operação manual constante. Em vez de ampliar indefinidamente o time responsável pela plataforma, o foco passou a ser construir sistemas capazes de distribuir responsabilidade de forma segura e observável entre toda a engenharia.

Esse modelo também muda a relação entre times de produto e infraestrutura. Quando ownership passa a existir diretamente no provisionamento, nas métricas e nas decisões automatizadas da plataforma, a infraestrutura se torna mais sustentável em escala. 

No fim, o desafio de operar mais de 21 mil databases não foi resolvido com mais controle centralizado, mas criando mecanismos que tornam responsabilidade e governança parte natural do próprio sistema. 

Conheça nossas oportunidades