O que é redundância em sistemas — e por que ela quase sempre quebra do jeito errado
Repetição de componentes não é o mesmo que confiabilidade. Muita gente confunde isso na hora de projetar infraestrutura. Você compra dois servidores, coloca um no active-passive e acha que resolveu o problema. Na prática, você só conseguiu duplicar um único ponto de falha se não pensou na arquitetura toda. A pergunta o que e redundante parece simples, mas a resposta depende inteiramente do que você está tentando proteger. Redundância em hardware é diferente de redundância em dados, que é diferente de redundância em rede, que por sua vez nada tem a ver com redundância em processos humanos. Misturar esses níveis é o erro mais comum que eu vejo acontecer.
o que e redundante na prática técnica
No nível mais básico, redundância significa ter mais de um caminho para algo funcionar. Se uma parte falha, outra assume. O detalhe que ninguém conta é que assumir não é automático — existe todo um mecanismo de detecção de falha, failover e sincronização envolvido. Sem isso, você tem dois componentes fazendo coisas diferentes e ninguém sabe qual é o verdadeiro. Eu trabalho com replicação de banco de dados há anos. A coisa mais importante que aprendi é que redundância síncrona é muito mais cara do que a maioria dos times entende. Quando você replica síncrona, cada escrita precisa ser confirmada nos nós redundantes antes de ser considerada completa. Em distâncias maiores que cem quilômetros, a latência do enlace já mata a performance. Você ganha consistência, perde tudo que é sensível a tempo. Replicação assíncrona resolve a latência, mas introduz window de perda de dados. Não existe solução perfeita aqui. Existe trade-off que você escolhe conscientemente ou que é escolhido por você quando não escolhe nada.
Um caso específico que me custou duas noites de sono foi com um cluster de armazenamento SAN que usava espelhamento síncrono entre dois datacenters. A equipe de rede não tinha configurado o STP corretamente entre os switches de camada distributiva. Quando um link oscilou, os dois nós do storage entraram em split-brain. Cada um escreveu dados diferentes no seu volume e quando o link voltou, a sincronização corrompeu partições inteiras. O workaround foi desabilitar o failover automático do storage, fazer resync manual com verificação checksum byte a byte, e reconfigurar o spanning tree com prioridade adequada no site primário. A correção final envolveu também aumentar o timeout de detecção de falha de três para quinze segundos para evitar flapping.
Tipos de redundância e quando cada um falha
Active-passive é o modelo mais comum e o mais subutilizado. O nó secundário fica parado, recebendo réplicas, pronto para assumir. O problema real é que o nó secundário nunca é testado até a falha acontecer. Eu já vi standby que tinha driver desatualizado, patch de segurança faltando, e configuração de rede levemente diferente do ativo. Quando o failover finalmente ocorreu, o standby nem bootou. O tempo de downtime foi o tempo de provisioning de uma máquina nova, não o tempo de failover. Active-active soa melhor porque ambos os nós processam carga. Mas aqui a complexidade sobe rapidamente. Você precisa de balanceamento de carga que entenda o estado da aplicação, mecanismos de lock distribuído se houver escrita concorrente, e lógica de resolução de conflitos se os dois nós modificarem os mesmos dados. O Kafka lida com isso bem porque foi construído para isso desde o início. Tentar transformar um sistema monolítico tradicional em active-active sem reescrever a camada de persistência geralmente termina em dados inconsistentes.
👉 Clique no botão abaixo para saber mais sobre o assunto!
N+1 é o modelo que a maioria das empresas usa sem perceber. Você tem N nós para suportar a carga normal mais um extra. Se um cai, os outros N sobrevivem. Parece sólido até você ter dois falhando ao mesmo tempo. A probabilidade de falhas simultâneas não é zero — é aproximadamente proporcional ao número de nós e ao tempo de exposição. Em clusters grandes, pelo menos duas falhas simultâneas por ano é estatisticamente esperado.
Métrica que importa e métrica que engana
SLA de 99,99% (four nines) corresponde a cerca de cinquenta e quatro minutos de downtime por ano. Parece pouco. Mas se o seu sistema de redundância precisa de vinte minutos para detectar falha mais dez para failover, você já gastou um quarto do seu orçamento anual de indisponibilidade em cada evento isolado. Redundância não elimina downtime. Ela reduz a probabilidade e a duração. A diferença é crucial. O que as pessoas esquecem de medir é o MTTR — mean time to recovery. Ter redundância com MTTR de horas não é redundância, é esperança. Um dos meus primeiros trabalhos foi migrar um ambiente onde o MTTR médio de failover era de quatro horas. A equipe achava que tinha alta disponibilidade porque existiam réplicas. Na prática, o processo de failover era manual, documentado em um wiki desatualizado, e ninguém testava. O MTTR caiu para onze minutos depois de automatizar o procedimento e colocar runbook em um sistema de playbooks executáveis.
Outra métrica que ninguém olha é a taxa de falsos positivos do sistema de detecção de falha. Se o mechanism de health check dispara failover toda vez que há uma picada de latência momentânea, você gera mais downtime com o failover do que teria deixando o nó doente rodando. Um caso real: um sistema de trading que fazia failover a cada 500ms de latência. A rede do datacenter tinha jitter natural de 300ms nos horários de pico. O resultado era um cluster em failover contínuo que nunca estabilizava. Ajustamos o threshold para dois segundos com janela de confirmação de três chamadas consecutivas. O problema parou.
Redundância de dados versus redundância de infraestrutura
Essa distinção é onde a maioria dos projetos erra. Você pode ter infraestrutura perfeitamente redundante e ainda assim perder dados. É o que acontece quando a replicação tem lag, quando o backup não é testado, ou quando o processo de restore não é praticado. Backup é redundância de dados. Restauração é redundância de processo. Eu tive um cliente que tinha replicação síncrona entre dois datacenters, backup diário em fita, e snapshot a cada hora. Parecia robusto. Quando um erro de delete em massa aconteceu às 3h da manhã, a replicação síncrona espalhou o erro para o secundário em segundos. O backup em fita tinha três dias de lag. Os snapshots tinham sido tirados antes do erro mas o processo de restore levou seis horas porque a equipe não tinha feito um teste de restauração completo em cento e vinte dias. Os dados foram recuperados, mas a empresa perdeu um dia inteiro de operação.
O conselho pragmático é simples e chato: testar failover periodicamente, medir o tempo real de recuperação, verificar a integridade dos dados após cada teste, e documentar tudo. Redundância sem teste é apenas uma aposta disfarçada de engenharia. O nível de redundância que você precisa deve ser definido pelo custo do downtime, não pelo custo dos componentes. Se o seu negócio perde cem mil reais por hora de indisponibilidade, investir duzentos mil em redundância adequada faz sentido. Se você não sabe quanto perde por hora, isso é o primeiro problema que precisa resolver antes de qualquer discussão sobre redundância. O conceito de o que e redundante só faz sentido quando vinculado a um risco específico que você está disposto a pagar para mitigar. Tudo além disso é gasto desnecessário ou falsa sensação de segurança. Os dois conceitos opostos — sub-redundância e over-redundância — são igualmente perigosos e igualmente comuns. O equilíbrio certo existe, mas exige medição contínua, não configuração definida uma vez e esquecida.
