Nubank processa 1 trilhão de logs por dia com plataforma própria na AWS

Quem opera CloudWatch, Fluent Bit ou qualquer pipeline de logs sabe o ponto em que a conta do fornecedor de observabilidade começa a doer mais que o próprio incidente que ele deveria ajudar a resolver. Foi exatamente aí que o Nubank chegou entre 2019 e 2023, segundo um post técnico assinado por engenheiros do banco e arquitetos de soluções da AWS publicado no blog da AWS Brasil. A solução, batizada de Alexandria, hoje ingere mais de 1 trilhão de linhas de log por dia e está em produção como plataforma padrão desde meados de 2024.

De 55 TB por dia a um problema de arquitetura

Em 2021 o Nubank processava cerca de 55 TB de logs por dia, crescendo perto de 100% ao ano. A arquitetura dependia de uma plataforma de logging de terceiros: cada microsserviço enviava dados direto para a API do fornecedor, via forwarders proprietários, sem nenhuma camada própria no meio do caminho.

Isso criava um pacote de riscos operacionais que qualquer time de observabilidade reconhece:

• Sem portabilidade: alertas, dashboards e dados históricos viviam só no ambiente do fornecedor.
• Sem soberania de dados: nenhuma filtragem, agregação ou regra de negócio antes do dado sair da infraestrutura do banco.
• Vendor lock-in: trocar de fornecedor exigiria reescrever integrações em milhares de microsserviços.
• Observabilidade furada: mais de 40% dos logs se perdiam entre a origem e o destino, criando pontos cegos durante incidentes.
• Custo imprevisível: a fatura virou um dos maiores itens do orçamento de infraestrutura, sem relação clara com o uso real.

Somado a isso, ingestão e consulta não eram desacopladas: pico de ingestão derrubava a performance das buscas, e vice-versa. Era o sintoma clássico de uma arquitetura monolítica tentando fazer dois trabalhos com perfis de carga opostos.

Por que construir em vez de trocar de fornecedor

A decisão do Nubank não foi "vamos reescrever logging porque dá pra fazer melhor". O próprio post é explícito sobre o critério: construir plataforma própria só se sustenta quando há volume que justifique o investimento, equipe dedicada de engenharia de plataforma e exigência regulatória de controle total sobre os dados. Para um banco digital operando em múltiplas jurisdições, com retenção de dados sujeita a auditoria por país, esse terceiro critério pesou tanto quanto o custo.

O nome escolhido, Alexandria, remete à antiga biblioteca: um sistema para coletar, preservar e dar acesso a um volume de informação que nenhuma prateleira comercial comportaria sem custo proibitivo.

O pipeline de ingestão, do pod ao S3

O Nubank dividiu o projeto em dois blocos: streaming (ingestão) e armazenamento/consulta. A base de execução é o Amazon EKS, orquestrando microsserviços com Karpenter para escalar nós elasticamente e Fluent Bit como DaemonSet coletando logs de cada pod. O fluxo, do dado gerado à consulta disponível, segue assim:

1. Cada aplicação rodando no EKS gera logs continuamente.
2. O Fluent Bit, como DaemonSet, acumula esses logs por alguns segundos e os envia ao Serviço Acumulador.
3. O Acumulador recebe os micro-batches, faz upload para o Amazon S3 e notifica uma fila no Amazon SQS sobre cada arquivo criado. Em 2025, esse componente sustentou picos de até 55 GB por segundo.
4. O Serviço de Filtro, desenvolvido internamente, baixa os chunks do S3, aplica regras de negócio, enriquece os dados e coleta métricas operacionais.
5. Uma solução interna converte os dados filtrados para Apache Parquet e grava no S3 em formato colunar.
6. Um serviço de compactação contínua consolida os arquivos pequenos, já que a ingestão quase em tempo real (latência abaixo de 1 minuto) chegava a gerar mais de 500 mil arquivos pequenos por segundo nos picos.

O desenho usa S3 como camada de persistência e SQS como barramento entre estágios. É a peça central do trade-off de confiabilidade: ingestão e processamento escalam de forma independente, sem um lado degradar o outro quando o tráfego dispara.

Trino, Parquet e o esquema padronizado de logs

Com os dados no S3, a escolha do motor de consulta recaiu sobre o Trino, por quatro razões que o post detalha: particionamento nativo por serviço e data, leitura direta do S3 sem banco intermediário, interface SQL que a equipe já conhecia e escalabilidade horizontal sem redesenho de arquitetura.

Para viabilizar isso, 99% dos microsserviços do Nubank adotaram um esquema padronizado de log, com os campos timestamp, body, service, type, level e cid (o ID de correlação entre serviços). Uma consulta de investigação de incidente fica assim:

SELECT * FROM nu.logs
WHERE
  service = 'my-service'
  AND type = 'ERROR'
  AND date = DATE '2025-09-25'
ORDER BY time DESC

O campo date não vem do schema de log em si: é uma coluna de partição derivada do timestamp, existindo só para orientar o Trino a escanear apenas o prefixo relevante no S3. É uma decisão de modelagem de dados pura, pensada para reduzir I/O, não para refletir um campo de negócio.

A camada de experiência fica num plugin customizado do Grafana, com uma DSL própria para esconder a verbosidade do SQL de quem só quer buscar um erro específico. Isso importa para quem vive de CloudWatch Logs Insights ou de queries ad hoc: a lição do Nubank é que, em escala de trilhão de linhas, a interface de consulta vira produto interno, não só uma tela a mais.

Os números e o que eles custaram em engenharia

Os resultados reportados dão a dimensão do salto em relação aos 55 TB/dia de 2021:

A compressão de cerca de 95% do Parquet é o que torna esses 45 PB pesquisáveis economicamente viáveis; sem ela, manter 45 dias de retenção num volume de 1 PB/dia teria uma conta de armazenamento bem diferente. É o pilar de otimização de custos do Well-Architected Framework aparecendo de forma concreta: a arquitetura não é mais rápida por acaso, ela é mais barata porque o formato de dado foi tratado como decisão de arquitetura, não detalhe de implementação, como o próprio post destaca.

Para quem isso vale, e para quem não vale

O Nubank é taxativo ao listar pré-requisitos: só compensa construir uma plataforma própria de logs quando o volume justifica o investimento, existe equipe dedicada de plataforma e há exigência regulatória real de soberania sobre os dados. Fora desses três critérios, a conta muda de lado: manter um fornecedor gerenciado de observabilidade continua sendo mais barato em tempo de engenharia do que operar um pipeline de streaming, um motor Trino e um serviço de compactação contínua.

Para quem administra logging em escala menor, dois padrões do Alexandria valem a pena isolados do resto da arquitetura: notificações de evento do S3 para o SQS eliminando polling entre estágios, e DLQs no SQS para isolar falhas sem travar o pipeline principal. São práticas de excelência operacional que não exigem reconstruir nada do zero.

O post da AWS também adianta o próximo passo do Nubank: expandir o Alexandria para novas regiões da AWS com políticas de retenção adaptadas a cada jurisdição, e investigar incidentes com ajuda de IA correlacionando logs, métricas e traces numa única narrativa de observabilidade, um território que a maioria dos times de SRE ainda está testando com ferramentas prontas, não construindo internamente.

Fonte: AWS Brasil — Blog