A chuva do cloud computing é de molhar bobo

O que há em comum entre os serviços Adobe, Alexa, Fortnite, iFood, Mercado Livre, Netflix, OLX, PicPay, Perplexity AI, Prime Video, Reddit, Roblox, Signal, Slack, Snapchat, Trello, Zoom, Amazon.com e o PIX em alguns bancos? Há o uso da região us-east-1 do serviço de cloud computing AWS, que os deixou fora do ar no último dia 20. Em alguns casos por mais de 10h consecutivas. No último dia 29, a concorrente Azure também passou por um apagão, deixando outras milhares de empresas paradas. O que há nessa chuva de problemas do cloud computing que as empresas ainda não aprenderam para deixar de se molhar?

O código us-east-1 representa a costa leste dos EUA, apenas uma das 38 regiões em que a AWS possui servidores hospedados em data centers e os aluga para outras empresas. Isso significa que os clientes que rodam seus sistemas em outras regiões, como sa-east-1, que representa São Paulo, não foram afetados neste último incidente.

No meu ramo profissional há um ditado que diz que “quem tem um, tem nenhum”. Para que se tenha dois de forma que ao menos um esteja sempre funcionando, a própria AWS oferece serviços de espelhamento de dados entre regiões diferentes de seus data centers. Uma explicação elegante para o que você conhece como backup. Se uma falha numa região ocorrer, softwares, sistemas, sites e apps passam a funcionar na última cópia feita em outros servidores, em outras edificações e até em outros países.

O erro é mais pedagógico do que o acerto e um erro grande deveria ensinar muito. Não é o caso. Mesmo o prejuízo de cada incidente sendo precificado em bilhões de dólares, não se trata de um evento raro. Somente na AWS tivemos ocorrências de grande porte em 2011, 2012, 2017, 2020, 2021 e agora duas vezes em 2025.

Notou o padrão? A média de um incidente a cada 3 anos tem a distância exata para que gestores fiquem com a impressão de que o pior já passou. No dia em que a nuvem cai, impedir um novo tombo se torna a prioridade da semana. Porém, implantar todas as contramedidas exigem meses de trabalho. No segundo ano a pauta é até lembrada, mas sem a prioridade de antes. Até que no terceiro cai no esquecimento, o tempo exato para que uma nova tempestade se forme e o apagão se repita.

Com profissionais de TI tão jovens e rotatividade tão elevada nos departamentos de tecnologia, falta um grisalho no time com 6 anos de casa que diga: –  “Vai dar m… já vi isso acontecer duas vezes” – e que seja escutado pela liderança técnica.

É possível construir aplicações que continuem operando mesmo quando um data center fica inoperante. É o que nos ensina de forma didática o teorema CAP, criado por Eric Brewer em 1998 durante a pré-história das Pontocom. Quando construímos sistemas distribuídos, apenas podemos escolher duas das três propriedades do teorema.

Os três elementos básicos são representados pela sua primeira letra em inglês: C representa a propriedade de consistência, em que qualquer usuário no mundo interagindo com o sistema obtenha a mesma resposta para a mesma consulta. A letra A representa a disponibilidade (availability), a capacidade do sistema estar disponível para o usuário. E P representa a tolerância à partição, a divisão entre os servidores com a perda da comunicação entre si, como os abrigados em data centers de países diferentes que não se comunicam mais, porém, ainda são acessíveis por usuários de cada país.

Como o teorema diz que só é possível escolher duas dessas propriedades, se quisermos que um sistema tenha alta disponibilidade ao mesmo tempo que tenha alta consistência, formando a sigla CA, teremos que abrir mão da capacidade de partição. Para que uma transação seja consistente, todos os múltiplos servidores que hospedam a aplicação pelos múltiplos data centers no mundo precisam receber ao mesmo tempo a mesma transação.

E esse sistema só deixará o usuário prosseguir quando todos os servidores tiverem confirmado o recebimento do novo dado. Caso um dos servidores não esteja respondendo, não é possível garantir que os dados armazenados nele sejam iguais aos do resto da frota. Como resultado, todo o sistema paralisa e se torna indisponível como vimos nos clientes da AWS que ficaram fora do ar neste apagão.

Se nos fosse pedido para assegurar que um sistema sobreviva ao próximo incidente dentro dos próximos 3 anos, precisamos garantir a maior disponibilidade possível (A) junto à tolerância da perda de comunicação entre os data centers (AP). Como cada escolha é uma renúncia, teremos que abrir mão da consistência: servidores diferentes guardarão dados ligeiramente diferentes, desatualizados entre si, sem que o sistema como um todo pare.

É por isso que nas redes sociais o número de likes e visualizações de um vídeo pode variar para cima ou para baixo cada vez que você carrega a tela. Elas são sistemas distribuídos do tipo AP, portanto, sem consistência.

Agora nos resta olhar para cada jornada do usuário e decidir quais propriedades queremos suportar em cada uma delas. Esse exercício permitirá o desenho de arquiteturas que em vez de ficarem totalmente fora do ar quando um fornecedor, uma nuvem falhar, a maior parte das funcionalidades continuarão acessíveis para o usuário com o menor prejuízo possível.

Pensando num comércio eletrônico, a quantidade de itens em estoque de cada produto pode muito bem ser do tipo AP, ou seja, abrir mão da consistência para continuar disponível. Mesmo que um servidor ache que há 10 itens em estoque enquanto havia 9, após as poucas horas que esses apagões costumam durar, podemos com uma automação cancelar o pedido do décimo cliente com o qual não poderemos honrar. Ou disparar novo pedido de compra para um fornecedor e repor o estoque.

E o cliente? Ele será avisado que a entrega atrasará e um cupom de desconto pode amenizar a frustração. Um cenário bem melhor do que simplesmente a página não carregar como alguns dos e-commerces afetados no último dia 20.

No mesmo comércio eletrônico que eu e você estamos redesenhando, faremos que as automações de estorno de valores aos clientes sejam do tipo CA, ou seja, toda informação disponível será consistente (C) ou não estará disponível (A). Assim, caso parte dos servidores esteja fora do ar no momento em que o cliente pede um estorno, o pedido será negado com uma mensagem de erro pedindo que volte mais tarde, pois o sistema está indisponível.

Ou ainda, podemos dizer ao usuário que todo pedido de estorno é submetido a uma análise e que a resposta será dada por e-mail em 1 dia. Assim, a aplicação pode esperar todos os servidores normalizarem para confirmarem a transação de forma unânime ou, se excedido o prazo, que o e-mail informe o indeferimento ao cliente e o oriente a tentar repetir a transação. Conquistamos assim uma abordagem CP, que garante a consistência enquanto tolera a partição de comunicação entre os servidores por um prazo sem interromper a jornada do cliente como um todo.

Do contrário, sem uma abordagem CA ou CP, é possível que o cliente acidentalmente repita o mesmo pedido de estorno e seja atendido por servidores  diferentes que não se comunicam entre si durante uma falha, recebendo assim duas vezes o estorno do mesmo valor. Na sorte do cidadão pagador de boleto, cobrança em duplicidade até acontece, mas renda em duplicidade nunca ocorre. Já notou isso?

Com esse exercício concluído, posso agora jogar minha luz sobre o impacto dos recentes apagões a tantas empresas importantes e populares. Carros possuem roda sobressalente porque pneus furam de tempos em tempos. A culpa por uma viagem parada por um pneu furado e um estepe murcho que não o substitui não deve recair sobre os buracos da estrada nem sobre as chuvas que os erodiram, mas sim sobre os ombros do motorista que foi omisso.

Diferentemente do que concluíram outros comentadores, esses incidentes não demonstram que a Internet é frágil. Não temos uma concentração perigosa de mercado e nem a computação em nuvem merece desconfiança. Todos os prejuízos foram autoinfligidos e eram evitáveis, causados pela falta de aprendizado entre as reincidências de casos espaçadas em anos e no desconhecimento das boas práticas de redundância em sistemas distribuídos.

Quanto a você, programador ou gestor, note que nunca falei que seria fácil. Você tem brio? O Brewer teve que criar o teorema CAP do zero 27 anos atrás. Cabe a você apenas estudar, entender e aplicar. Classe encerrada. Não esqueçam seus guarda-chuvas! Veremo-nos a qualquer momento até 2028.