Imagine duas empresas com dois links de internet e fornecedores diferentes. À primeira vista, as duas parecem ter uma boa estratégia de redundância. Até que uma falha acontece. Uma continua operando normalmente; a outra fica offline.
Como isso é possível se ambas tinham dois links?
Porque ter dois caminhos não significa, necessariamente, ter dois caminhos diferentes. E essa diferença pode ser muito maior do que parece.
Redundância não é simplesmente ter um plano B
Quando se fala em continuidade de conectividade, a primeira reação costuma ser pensar em uma segunda conexão. Se uma cair, a outra assume. Na teoria, parece simples.
Mas existe uma pergunta que muitas vezes fica de fora: o segundo caminho realmente é independente do primeiro?
Imagine, por exemplo, duas conexões contratadas com empresas diferentes. Parece uma boa estratégia. Mas e se as duas utilizarem a mesma rota física? Ou passarem pelo mesmo ponto de entrada? Ou dependerem da mesma infraestrutura em determinada região? Ou convergirem para o mesmo data center?
Nesse cenário, existem dois contratos e talvez dois fornecedores, mas existe apenas um caminho físico para a operação. E, se esse caminho falhar, os dois links podem falhar juntos.
É aí que a redundância deixa de ser uma questão de quantidade e passa a ser uma questão de diversidade.
Quando a rota atravessa oceanos
A maioria das pessoas não pensa na infraestrutura internacional quando acessa uma aplicação hospedada em outro país. Um clique parece simples, mas, por trás dele, existe uma cadeia de redes que pode atravessar cidades, países e oceanos.
Cabos submarinos formam uma das principais bases dessa infraestrutura. Segundo a União Internacional de Telecomunicações, mais de 99% do tráfego internacional de dados passa por cabos submarinos. São eles que sustentam serviços que vão de comunicação e serviços financeiros a cloud computing e outras operações digitais.
O problema é que essa infraestrutura, apesar de enorme, não é invulnerável.
Cabos podem ser afetados por atividades humanas, como pesca e ancoragem, além de terremotos, tempestades, correntes marítimas, falhas de equipamentos e outros eventos. A ITU estima que ocorram cerca de 200 falhas em cabos submarinos por ano, sendo mais de 80% associadas a atividades de pesca e ancoragem.
Isso não significa que a internet global esteja constantemente perto de parar. Significa algo mais importante para quem administra uma operação: a infraestrutura que parece invisível também precisa de caminhos alternativos.
O mapa importa mais do que a quantidade
Existe uma diferença importante entre uma falha física e uma falha de arquitetura.
Um cabo pode estar funcionando perfeitamente, o problema pode estar no fato de que diferentes conexões dependem dele.
Pense em uma estrada. Você tem duas estradas para chegar ao mesmo destino, parece redundante, mas as duas passam pela mesma ponte. Se a ponte fechar, você não tem duas alternativas, tem duas estradas que levam ao mesmo problema.
Em redes, a lógica é parecida, uma arquitetura realmente resiliente precisa considerar diferentes elementos: rota física, infraestrutura, pontos de entrada, fornecedores, regiões, data centers e caminhos internacionais.
Quanto mais desses elementos forem compartilhados, maior pode ser a dependência escondida.
Por isso, diversidade geográfica se tornou uma das discussões centrais sobre a resiliência das redes internacionais.
Em julho de 2026, a ITU aprovou um conjunto de recomendações internacionais voltadas justamente ao fortalecimento da resiliência dos cabos submarinos. Entre as prioridades estão o aumento da diversidade geográfica e da redundância, além de melhorias na identificação de riscos, monitoramento, preparação e resposta a falhas.
Isso ajuda a explicar por que duas empresas com o mesmo número de links podem apresentar níveis de resiliência completamente diferentes.
Uma pode ter caminhos distribuídos por regiões e infraestruturas distintas. A outra pode ter conexões que parecem diferentes na proposta comercial, mas dependem dos mesmos elementos físicos.
No papel, ambas têm redundância.
Na prática, não.
Quando o problema acontece longe da sua empresa
Esse é talvez o ponto mais contraintuitivo.
Uma empresa pode estar funcionando perfeitamente. Seus equipamentos estão ligados, seus switches estão operacionais, seus servidores estão funcionando e seu link local parece normal. E, ainda assim, sua operação pode ser afetada por uma falha que aconteceu centenas ou milhares de quilômetros dali.
A própria ITU destaca a concentração geográfica da infraestrutura e a dependência de alguns países de um número reduzido de sistemas de cabos como fatores de vulnerabilidade.
Em 2024, por exemplo, Tonga enfrentou um período de isolamento após uma falha em cabo submarino. A ITU utiliza o caso como exemplo de como uma dependência excessiva de um único caminho pode deixar uma região vulnerável.
A distância física entre a empresa e o problema não reduz necessariamente o impacto. Em uma economia conectada, uma falha pode viajar pela rede muito mais rápido do que qualquer equipe consegue chegar até o ponto onde ela aconteceu.
Redundância também é tempo
Ter uma rota alternativa não significa necessariamente que ela será ativada instantaneamente ou que terá capacidade suficiente para absorver toda a operação.
A resiliência precisa considerar também: quanto tempo leva para detectar a falha? Quanto tempo leva para mudar o tráfego? A rota alternativa suporta a demanda? Existe capacidade disponível? O fornecedor consegue atuar rapidamente? Há uma rota realmente independente? Quanto tempo levaria para reparar a infraestrutura principal?
Essas perguntas transformam a redundância em algo mais amplo do que um simples “link backup”. Ela passa a ser uma estratégia de continuidade.
É comum que decisões de conectividade sejam avaliadas principalmente por preço, capacidade e SLA. Esses critérios são importantes, mas podem não contar toda a história.
Duas propostas podem entregar a mesma velocidade, apresentar SLAs semelhantes e até oferecer fornecedores diferentes. Mas, se uma arquitetura concentra suas rotas em uma mesma infraestrutura física e a outra distribui seus caminhos, elas não estão entregando exatamente o mesmo nível de resiliência.
Às vezes, o que parece uma pequena diferença de arquitetura é, na verdade, uma diferença enorme de risco.
O melhor caminho talvez seja aquele que você espera nunca precisar usar
Existe uma característica curiosa da redundância: quando ela funciona, ninguém percebe.
A operação continua. Os usuários continuam acessando os sistemas. As aplicações continuam respondendo. O cliente não sabe que alguma coisa aconteceu.
E esse é justamente o objetivo.
Uma boa arquitetura de resiliência não existe para aparecer. Ela existe para que determinados problemas não precisem aparecer para quem está do outro lado da operação.
Mas, para isso, é preciso conhecer os caminhos antes que eles sejam necessários. Saber onde estão, entender o que compartilham, identificar quais são realmente independentes e descobrir quais pontos poderiam derrubar tudo ao mesmo tempo.
No fim, a pergunta não deveria ser apenas: “Quantos links temos?”
Talvez a pergunta mais importante seja: “Quantos caminhos diferentes existem, de verdade, entre nossa operação e aquilo de que ela depende?”
Porque, quando a conectividade é parte da operação, redundância não é ter um segundo caminho.