2.000 anos debaixo de água salgada e ainda mais forte que quando foi feito. O teu software aos 2 meses já tem bit rot.
O Panteão de Roma, a Cúpula de 43 metros de diâmetro, foi construído em 128 d.C. com betão. Ainda hoje é a maior cúpula de betão não-armado do mundo. Os molhes dos portos romanos, submersos há milénios, estão mais intactos que muitos quebra-mares modernos.
Durante décadas, os cientistas perguntaram-se: como é que o betão romano dura tanto? O nosso betão moderno (cimento Portland) degrada-se em décadas — especialmente em ambiente marinho. O betão romano parece melhorar com o tempo.
Neste artigo vais aprender:
- O mecanismo químico que torna o betão romano auto-reparável
- A descoberta dos "lime clasts" (clastos de cal) em 2023
- Analogias com engenharia de software — sistemas que melhoram com a idade
- Lições para a forma como construímos sistemas hoje
⬆ O mecanismo de auto-reparação: clastos de cal dissolvem-se em fissuras e recristalizam como carbonato de cálcio, selando a fractura.
O mecanismo químico
Em Janeiro de 2023, uma equipa do MIT liderada por Admir Masic publicou no Science Advances a descoberta chave: os lime clasts (clastos de cal).
O betão romano era feito com cal viva (CaO) em vez de cal hidratada, misturada com cinza vulcânica e água. O processo de mistura a quente ("hot mixing") produzia pequenas partículas brancas de cal — os clastos. Estes clastos são frágeis e quebram-se quando o betão fissura. A água infiltra-se, dissolve o clasto, e a solução rica em cálcio reage com o ar para formar carbonato de cálcio (CaCO₃), que preenche a fissura.
O processo é autónomo, auto-suficiente e infinito enquanto houver clastos e água. Cada fissura gera novo material que sela a fractura.
O que isso tem a ver com software?
O betão romano incorpora o que os engenheiros de software chamariam um feedback loop de reparação. Vamos buscar as analogias:
Bit rot vs. auto-reparação
O nosso software sofre de bit rot (degradação do código): dependências desactualizadas, bugs acumulados, dívida técnica. Cada "fissura" no código (um bug, uma vulnerabilidade) precisa de intervenção manual para ser reparada. O betão romano repara as fissuras sozinho.
Hot mixing = design patterns
O "hot mixing" dos romanos era intencional — sabiam que criar clastos de cal no betão era essencial para a longevidade. Em software, os design patterns e arquitecturas resilientes são os nossos "clastos". Quando o sistema falha, esses patterns (retry logic, circuit breakers, graceful degradation) preenchem a "fissura" automaticamente.
Cinza vulcânica = composição modular
A cinza vulcânica (pozolana) reagia com a cal para formar a matriz do betão. Em software, são as bibliotecas modulares e frameworks que compõem o sistema. A qualidade da reacção depende da qualidade dos componentes.
Analogia central: O betão romano foi desenhado (ou descoberto empiricamente) para ter redundância química. Quando uma parte falha, o material circundante reage para a reparar. Em sistemas de software, isto chama-se resiliência. Mas poucos sistemas a têm de forma verdadeiramente autónoma — a maioria precisa de um humano a fazer root cause analysis e a aplicar o hotfix.
Sistemas que melhoram com a idade
O betão romano não é o único sistema que melhora com o tempo. Eis alguns exemplos familiares a developers:
- Unix / Plan 9 — sistemas operativos desenhados há décadas, cujos princípios (tudo é ficheiro, pipes, composição) se mantêm sólidos porque a arquitectura é simples e bem pensada.
- IP / TCP — o protocolo que fundou a Internet. Desenhado nos anos 70 com falhas (como a falta de segurança nativa), mas a arquitectura de camadas e o design descentralizado permitiram que evoluísse sem colapsar.
- SQLite — 25+ anos de existência. Cada bug encontrado é estudado, documentado, e o código é extensivamente testado. Melhora com a idade porque o feedback loop é sistemático.
- Git — o modelo de objectos (blobs, trees, commits) desenhado por Linus Torvalds em 2005 mantém-se quase inalterado. A estrutura interna é tão sólida que o software à volta evolui sem precisar de mudar o core.
O que estes sistemas partilham com o betão romano? Simplicidade na arquitectura fundamental + mecanismos de auto-reparação.
Bit rot e dívida técnica
A maioria do software moderno sofre do oposto da auto-reparação: bit rot acelerado. As causas são conhecidas:
- Dependências que se actualizam com breaking changes frequentes (JavaScript ecosystem, looking at you)
- Arquitecturas monolíticas sem boundaries claras
- Falta de testes que detectem regressões
- Ausência de mecanismos de "reparação automática" — health checks, self-healing, circuit breakers
Se o betão romano fosse software, teria auto-scaling, self-healing e chaos engineering embutidos no material. Não precisava de um SRE a fazer deploy de um hotfix — o próprio sistema fechava a fissura.
Implicações para engenheiros de software
O que podemos aprender com o betão romano?
- Desenha para falhar, não para durar. O betão romano parte-se de propósito (os clastos são frágeis). Cada fissura desencadeia a reparação. Em software, planeia falhas: circuit breakers, retries, fallbacks.
- Incorpora redundância no material base. Em vez de add-ons externos (monitoring, alerting), a resiliência deve estar na arquitectura. Testes, tipos, invariantes.
- Processos lentos e estáveis vencem. O betão romano não cura em horas — cura ao longo de décadas, ficando mais forte. Em software, ciclos lentos de feedback e refactoring contínuo produzem sistemas mais robustos que sprints apressados.
- Estuda o que já funciona há milénios. Unix, TCP, Git, SQLite — são os "betões romanos" da engenharia de software. Vale a pena perceber porque duram.
Conclusão
A descoberta dos lime clasts no betão romano não é apenas cool science — é uma lição intemporal de engenharia. O Império Romano caiu há 1.500 anos, mas o betão deles ainda está de pé. Quanto do teu software actual vai durar 10 anos? 50? 100?
Talvez seja altura de pensar menos em "shipping rápido" e mais em "construir para durar".
Comentários (0)
Nenhum comentário ainda. Seja o primeiro!
Deixar comentário