Arquitetura que sobrevive: decisões que não precisam ser refeitas
As melhores decisões arquiteturais não são as mais inteligentes — são as que continuam certas quando o contexto muda.
Em 28 anos construindo e consultando sobre sistemas, desenvolvi um conjunto de critérios para avaliar decisões arquiteturais. O principal deles não é performance, não é elegância, não é custo.
É durabilidade.
Uma decisão arquitetural boa é aquela que continua sendo boa quando o time muda, quando o produto cresce, quando o mercado muda, quando a tecnologia evolui.
O problema com a arquitetura “inteligente”
Existe uma tendência nos times de engenharia de confundir sofisticação com qualidade. Microserviços quando um monólito bem estruturado seria suficiente. Event sourcing onde CRUD resolve. Arquitetura reativa em sistemas que têm 100 usuários.
Não é falta de competência — é o problema oposto. Engenheiros competentes, confrontados com problemas simples, tendem a aplicar soluções complexas porque soluções simples parecem subestimar sua capacidade.
O resultado são sistemas que ninguém mais consegue manter.
Os critérios que uso
Quando avalio uma decisão arquitetural, faço estas perguntas:
1. Um engenheiro novo consegue entender em 30 minutos?
Se a resposta for não, a arquitetura já tem um problema. Sistemas que dependem de conhecimento tribal — conhecimento que só existe na cabeça de quem os construiu — são sistemas frágeis.
Isso não significa arquitetura simplória. Significa arquitetura que se explica bem.
2. Qual é o custo de reverter?
Algumas decisões são baratas de reverter. Trocar um serviço de email é simples. Trocar o banco de dados principal de uma aplicação com 5 anos é caro.
Decisões difíceis de reverter precisam de mais evidência antes de serem tomadas. E quando são tomadas, precisam ser documentadas — não o que foi decidido, mas por que foi decidido com aquele contexto.
3. O que acontece quando dobrar de tamanho?
Não estou falando de escala infinita. Estou falando do próximo passo realista. Se a aplicação tem 1.000 usuários, o que acontece com 10.000? Se tem 10.000, com 100.000?
Arquitetura que só funciona no tamanho atual não é arquitetura — é prototipagem.
4. Qual é o pior modo de falha?
Todo sistema falha. A questão é como. Sistemas bem arquitetados falham de forma previsível, detectável e, idealmente, degradam graciosamente.
Exemplo: um sistema que trava completamente quando o banco de dados
fica lento é pior do que um sistema que serve dados em cache ligeiramente
desatualizados enquanto o banco se recupera.Decisões que envelhecem bem
Algumas categorias de decisões que consistentemente envelhecem bem:
Separação de dados por domínio: Mesmo em um monólito, dados de domínios diferentes com fronteiras claras são mais fáceis de escalar depois.
Contratos explícitos entre componentes: Interfaces bem definidas permitem trocar implementações. O contrário amarra o sistema a escolhas que eram corretas em 2020 mas não em 2025.
Logs estruturados desde o início: Observabilidade é muito mais barata quando planejada do que quando adicionada depois.
Configuração separada do código: 12-factor não é apenas boa prática — é o que separa sistemas que funcionam em múltiplos ambientes de sistemas que só funcionam na máquina do engenheiro que os criou.
O que documento em toda decisão arquitetural
Quando registro uma decisão arquitetural (Architecture Decision Record), incluo sempre:
- Contexto: O que estava acontecendo quando essa decisão foi tomada?
- Alternativas consideradas: O que mais foi avaliado?
- Decisão: O que foi escolhido?
- Consequências: O que ganhamos? O que abrimos mão?
- Data e contexto de revisão: Quando isso deve ser reavaliado?
Esse último item é ignorado pela maioria. Uma ADR sem data de revisão é uma decisão que vai persistir indefinidamente, mesmo quando o contexto que a justificou não existe mais.
A conclusão
A arquitetura não é sobre tecnologia. É sobre decisões que sobrevivem ao tempo, ao crescimento e à mudança de pessoas.
Quando alguém me pergunta qual tecnologia usar, minha primeira pergunta é: “Para que contexto, com qual time, com qual horizonte de tempo?”
Porque a resposta certa depende da resposta a essas perguntas — não de qual é a tecnologia mais popular hoje.
Quer discutir as decisões arquiteturais do seu sistema? Esse é exatamente o trabalho da INIT4.