Nubank fora do ar por uma tarde: o que a falha ensina a quem constrói sistemas

Na tarde desta sexta-feira, 14 de agosto, o aplicativo do Nubank parou de responder. Cartões foram recusados no meio de compras. A tela de saldo não carregava. Por algumas horas, milhões de pessoas que usam o banco como conta principal ficaram sem acesso ao próprio dinheiro — não porque ele tivesse sumido, mas porque a camada de software que dá acesso a ele deixou de responder.

O serviço voltou ao normal ainda no mesmo dia. Do ponto de vista de quem só queria almoçar, foi um transtorno passageiro. Do ponto de vista de quem constrói software, foi uma aula pública sobre uma coisa que costumamos tratar como detalhe: o que acontece quando a dependência que ninguém questiona para de funcionar.

O que se sabe e o que não se sabe

Comecemos pelo que é honesto dizer: até o momento, o Nubank não detalhou publicamente a causa raiz da instabilidade. Sabe-se que a falha foi generalizada, que atingiu simultaneamente aplicativo e função de cartão, e que a normalização levou algumas horas.

Essa ausência de detalhe é comum e compreensível — instituições financeiras costumam divulgar post-mortems com cautela, quando divulgam. Mas ela também é o motivo pelo qual a discussão útil aqui não é sobre o que o Nubank fez de errado. É sobre o que qualquer sistema com essa superfície de exposição enfrenta, e o que a arquitetura de quem está do outro lado deveria prever.

Porque a pergunta que interessa para quem desenvolve não é "por que caiu?". É: quando um serviço do qual meu sistema depende cair, o que acontece com o meu?

A dependência que ninguém desenhou

Vale olhar para o tamanho do que ficou indisponível. O Nubank não é apenas mais um app de banco no Brasil: é a conta principal de uma fatia enorme da população, e é também um meio de pagamento que aparece como opção em checkouts, assinaturas e cobranças recorrentes de milhares de negócios digitais.

Isso significa que a indisponibilidade não ficou contida no app. Ela vazou para fora. Um e-commerce que tinha o cartão como forma de pagamento viu conversão cair sem ter mudado nada no próprio código. Um SaaS com cobrança recorrente teve falha em transações que estavam programadas para aquele horário. Uma loja física que aceita pagamento por aproximação viu vendas travarem no caixa.

Nenhum desses sistemas tinha um item no backlog chamado "dependência do Nubank". A dependência existia mesmo assim — ela só não estava escrita em lugar nenhum.

Esse é o padrão que se repete em incidentes assim: as dependências que mais doem são justamente as que ninguém documentou, porque pareciam infraestrutura. Ninguém escreve "dependemos de a energia elétrica funcionar". Com serviços que atingem certa escala, acontece o mesmo — eles passam a ser tratados como parte do ambiente, não como um ponto de falha.

Falhar não é o problema. Falhar mal é.

Todo sistema em produção vai ficar indisponível em algum momento. Isso não é opinião pessimista, é estatística: quanto mais peças, mais chances de uma delas parar. A questão que separa um sistema bem construído de um mal construído não é a existência da falha, e sim o comportamento durante ela.

Um checkout que depende de um meio de pagamento pode reagir de várias formas quando esse meio não responde:

• Trava a tela e deixa o usuário no escuro. É o pior caso, e infelizmente o mais comum — a requisição fica pendurada até o timeout, e o cliente desiste sem entender o que houve.
• Mostra um erro genérico. Melhor que travar, mas ainda joga no cliente a responsabilidade de adivinhar se o problema é dele.
• Detecta a falha, comunica com clareza e oferece alternativa. "Esse meio de pagamento está indisponível no momento. Tente PIX ou outro cartão." O usuário perde alguns segundos, não a compra.

A diferença entre o primeiro e o terceiro caso raramente é tecnologia sofisticada. Em geral é um timeout configurado de forma consciente, um tratamento de erro que distingue "recusado" de "indisponível", e uma decisão de produto tomada antes do incidente sobre o que mostrar quando a integração falhar.

Timeout não é detalhe de configuração

Um detalhe técnico que merece atenção: muita integração de pagamento roda com o timeout padrão da biblioteca HTTP, que pode ser de dezenas de segundos ou simplesmente não existir. Numa falha do provedor, isso significa requisições penduradas ocupando conexões, threads ou instâncias — e o problema, que era do parceiro, vira seu.

Um serviço que responde "não consegui processar" em três segundos degrada com dignidade. Um que fica esperando trinta segundos por resposta acaba derrubando a si mesmo junto.

O que isso significa para quem desenvolve no Brasil

Aqui a conversa fica bem concreta, porque o cenário brasileiro tem particularidades que mudam o cálculo.

A primeira é a concentração. O mercado financeiro digital brasileiro tem alta participação de poucos players, e o PIX criou uma camada adicional de dependência compartilhada. Quando um elo com essa penetração oscila, o efeito não é local — ele atravessa setores inteiros ao mesmo tempo.

A segunda é o tamanho das equipes. A maior parte dos times de desenvolvimento no Brasil trabalha com poucos desenvolvedores e sem SRE dedicado. Não há plantão 24/7, não há war room. Isso não impede resiliência — mas muda o tipo de resiliência que faz sentido buscar. Não adianta desenhar arquitetura multirregião com failover automático se não há quem opere isso às seis da tarde de uma sexta.

O que cabe numa equipe pequena, e paga muito bem:

• Ter mais de um meio de pagamento ativo. Não como plano de contingência guardado numa gaveta, mas funcionando em produção, testado, pronto para virar o principal.
• Definir timeouts explícitos em toda chamada externa. Nenhuma integração deveria poder esperar indefinidamente.
• Escrever a mensagem de erro antes do incidente. No meio da crise ninguém escreve texto bom. Deixe pronta a copy que aparece quando o provedor cai.
• Monitorar a taxa de sucesso das integrações, não só o uptime do próprio servidor. Seu servidor pode estar em pé e respondendo 200 enquanto todas as transações falham.

Esse último ponto costuma ser o mais negligenciado. É comum uma equipe descobrir que o pagamento parou porque um cliente reclamou no WhatsApp, não porque o monitoramento avisou — o painel mostrava tudo verde, já que a aplicação estava saudável. O que caiu foi o terceiro.

A falha como informação

Há um ganho pouco explorado em incidentes públicos como esse: eles são um teste de carga gratuito da sua própria arquitetura. Enquanto o provedor estava fora, seu sistema fez o quê?

Vale reservar meia hora e olhar os logs daquela janela. As requisições falharam rápido ou ficaram penduradas? O erro que chegou ao usuário dizia algo útil? Alguém foi notificado, ou a descoberta veio pelo suporte? Existe registro de quantas transações se perderam?

As respostas a essas perguntas valem mais que qualquer documento de boas práticas, porque são sobre o seu sistema, com o seu tráfego, num evento real. E é bem mais barato aprender com a queda de um terceiro do que com a sua.

O que observar daqui pra frente

Duas coisas merecem acompanhamento. A primeira é se o Nubank publicará um relatório detalhado do incidente — a prática de post-mortems públicos ainda é rara no setor financeiro brasileiro, e cada vez que uma instituição grande adota, o mercado inteiro aprende junto.

A segunda, mais importante para quem desenvolve: se a concentração vai continuar aumentando. Quanto mais serviços dependem dos mesmos poucos provedores, mais qualquer oscilação vira evento sistêmico. Isso não é um problema que um time resolve sozinho — mas é um risco que dá para mapear, documentar e mitigar dentro de casa.

A pergunta que vale levar para a próxima reunião de arquitetura é simples e desconfortável: se o serviço mais crítico da nossa stack ficar quatro horas fora do ar amanhã, o que os nossos usuários vão ver? Se ninguém souber responder com certeza, essa é a próxima tarefa.