Em engenharia de software, existe uma tendência crescente de associar sistemas robustos a arquiteturas cada vez mais complexas. Microsserviços, Kubernetes, múltiplas camadas de abstração, bancos de dados distribuídos, filas, service meshes e dezenas de ferramentas de observabilidade são frequentemente apresentados como sinônimos de escalabilidade e alta disponibilidade. Entretanto, complexidade não é sinônimo de resiliência. Em determinadas circunstâncias, ela pode até representar uma nova superfície de falha. É nesse contexto que surge a Filosofia Salamandra: uma abordagem arquitetural baseada na ideia de que um sistema verdadeiramente resiliente não é aquele que jamais perde partes, mas aquele capaz de sobreviver à perda de partes sem deixar de cumprir sua função essencial.
A metáfora da salamandra representa justamente essa capacidade. Quando uma salamandra perde sua cauda, ela não deixa necessariamente de existir. O organismo continua funcionando enquanto uma nova cauda pode crescer. Aplicada à engenharia de software, a metáfora propõe uma mudança fundamental de perspectiva: em vez de concentrar esforços exclusivamente na prevenção de falhas, devemos também projetar sistemas capazes de absorvê-las.
Essa distinção é fundamental. Um sistema tradicional pode possuir um único componente responsável por diversas funções críticas. Enquanto esse componente estiver funcionando, tudo parece perfeito. Entretanto, quando ele falha, todo o sistema pode entrar em colapso. Trata-se de uma arquitetura altamente acoplada, na qual a disponibilidade de uma parte determina a disponibilidade do conjunto.
A Filosofia Salamandra propõe justamente o contrário. O sistema deve ser dividido em partes suficientemente independentes para que a falha de uma delas não provoque necessariamente a falha das demais. Um CMS pode cair sem derrubar o site público. Um sistema de comunidade pode ficar indisponível sem impedir o acesso aos imóveis. Um servidor pode ser comprometido sem conceder automaticamente controle sobre todos os outros serviços.
Nesse sentido, a filosofia se aproxima de conceitos conhecidos da engenharia de software, como isolamento de falhas, redundância, graceful degradation, bulkheads, failover e fault tolerance. Entretanto, ela acrescenta uma dimensão importante: a diversidade.
Redundância não significa simplesmente possuir dez servidores executando exatamente a mesma aplicação. Se todos dependem do mesmo sistema operacional, da mesma configuração, do mesmo banco de dados, da mesma rede e das mesmas credenciais, uma única falha pode atingir todos simultaneamente. A verdadeira resiliência exige a redução dos pontos de falha compartilhados.
Por isso, diferentes tecnologias podem exercer funções diferentes dentro do mesmo ecossistema. Um sistema pode utilizar WordPress para gerenciamento de conteúdo, HumHub para interação comunitária, outra aplicação para gerenciamento imobiliário e páginas estáticas para distribuição pública. Essa diversidade tecnológica não precisa ser vista como desorganização. Quando acompanhada de limites claros entre responsabilidades, ela pode funcionar como uma forma de isolamento.
Outro princípio fundamental da Filosofia Salamandra é a separação entre produção e distribuição.
Um CMS não precisa necessariamente estar no caminho crítico de cada acesso realizado por um visitante. Imagine um site cujo conteúdo é revisado por uma pessoa antes da publicação. Nesse cenário, o CMS pode funcionar como uma ferramenta editorial, enquanto o resultado aprovado é transformado em arquivos estáticos e distribuído por uma rede CDN.
Se o WordPress cair às três horas da manhã, o conteúdo já publicado continua disponível.
Essa característica revela uma importante distinção arquitetural: a indisponibilidade do sistema de publicação não precisa significar indisponibilidade do sistema de leitura.
O CMS pode estar completamente fora do ar e, ainda assim, o público continuar acessando HTML, CSS, JavaScript e imagens normalmente. A próxima publicação simplesmente aguardará até que o sistema editorial esteja novamente disponível.
Esse modelo também possui uma consequência importante para sistemas que dependem de confiabilidade das informações. Em vez de publicar imediatamente cada alteração recebida, as informações podem ser acumuladas em uma fila, submetidas a verificação humana e somente então incorporadas ao próximo build.
O atraso, nesse caso, deixa de ser uma deficiência e passa a ser um mecanismo de qualidade.
Uma atualização recebida hoje pode aguardar outras atualizações, ser comparada com informações anteriores, passar por uma análise humana e somente depois ser publicada. O processo pode ser representado da seguinte maneira:
WhatsApp → fila → verificação humana → aprovação → build → publicação.
O resultado é uma arquitetura na qual a ausência de automação total se transforma deliberadamente em uma camada de segurança e confiabilidade.
Essa ideia contraria uma das obsessões da engenharia moderna: a busca permanente pela atualização em tempo real. Nem todo sistema precisa ser real-time. Em muitos contextos, consistência eventual, processamento em lote e publicação periódica são mais adequados, baratos e seguros.
A Filosofia Salamandra, portanto, não rejeita a tecnologia. Ela rejeita a tecnologia utilizada sem uma necessidade correspondente.
Uma infraestrutura de milhares de reais pode ser perfeitamente justificável quando existe uma demanda real por ela. Entretanto, se um site possui algumas centenas ou milhares de acessos e pode ser servido por arquivos estáticos distribuídos por uma CDN, implementar uma infraestrutura extremamente complexa apenas porque ela é considerada moderna pode representar uma inversão de prioridades.
A pergunta correta não é:
“Qual é a arquitetura mais sofisticada que podemos construir?”
A pergunta deveria ser:
“Qual é a arquitetura mais simples capaz de sobreviver às falhas que realmente precisamos suportar?”
Essa diferença parece pequena, mas altera completamente o processo de engenharia.
A simplicidade também possui uma vantagem de segurança. Quanto menos componentes críticos existirem, menor tende a ser a superfície de ataque. Um site estático não precisa executar PHP para cada requisição, consultar um banco de dados ou interpretar código do CMS para entregar uma página já publicada. O conteúdo pode ser construído em um ambiente controlado e posteriormente distribuído como artefato imutável.
Surge então outro princípio da Filosofia Salamandra: a publicação deve ser tratada como criação de um artefato.
Cada build representa uma versão específica do sistema. Se uma nova versão apresentar problemas, a versão anterior pode ser restaurada. Dessa forma, a atualização deixa de ser uma alteração destrutiva no ambiente de produção e passa a ser a substituição de um estado conhecido por outro estado conhecido.
Build, publicação e rollback tornam-se operações previsíveis.
Isso também muda a maneira como pensamos sobre disponibilidade. Em vez de perguntar se cada componente possui disponibilidade de 99,999%, devemos perguntar qual é o impacto da indisponibilidade daquele componente.
Se o sistema de administração cair, talvez a publicação fique temporariamente indisponível.
Se o sistema de comunidade cair, talvez apenas a comunidade fique indisponível.
Se o CMS cair, talvez o conteúdo público continue funcionando.
A falha deixa de ser binária.
O sistema não precisa ser simplesmente “funcionando” ou “fora do ar”. Ele pode possuir diferentes níveis de degradação.
Essa é uma das características mais importantes da resiliência: permitir que o sistema perca capacidades sem perder sua identidade.
A Filosofia Salamandra também reconhece que nenhum sistema é completamente seguro contra falhas. Servidores falham. Discos morrem. Aplicações possuem vulnerabilidades. Configurações são alteradas incorretamente. Desenvolvedores cometem erros. Serviços externos ficam indisponíveis.
Tentar eliminar todas essas possibilidades é impossível.
Projetar para sobreviver a elas é possível.
Essa mudança de mentalidade aproxima a Filosofia Salamandra da engenharia de caos e da antifragilidade. Um sistema resiliente suporta o impacto de uma falha. Um sistema antifrágil utiliza as falhas como oportunidade para descobrir novas vulnerabilidades, corrigir processos e retornar mais forte.
Assim, uma falha pode produzir conhecimento.
Um servidor comprometido pode revelar uma falha de isolamento. Uma publicação incorreta pode revelar uma deficiência no processo de revisão. Um serviço indisponível pode revelar uma dependência desnecessária. Cada incidente pode gerar uma melhoria arquitetural.
A salamandra não é imortal.
Ela simplesmente não depende da permanência de cada uma de suas partes para continuar existindo.
Essa talvez seja a principal contribuição da Filosofia Salamandra para a arquitetura de software: abandonar a ideia de que robustez significa preservar todas as partes intactas.
Um sistema robusto pode ser aquele que aceita perder partes.
Pode perder um servidor.
Pode perder um CMS.
Pode perder uma aplicação.
Pode perder uma funcionalidade.
Pode até perder temporariamente uma fonte de dados.
Mas não precisa perder o todo.
No final, a verdadeira alta disponibilidade não consiste necessariamente em impedir que alguma coisa caia. Consiste em garantir que, quando alguma coisa inevitavelmente cair, sua queda não seja suficiente para derrubar todo o sistema.
A Filosofia Salamandra pode, portanto, ser resumida em um princípio simples:
Projete cada componente para funcionar bem, mas projete o sistema inteiro para sobreviver à ausência de qualquer componente individual.
Porque sistemas perfeitos não existem.
Sistemas que sobrevivem às próprias imperfeições, sim.
About the Author
