1. tudo na arquitetura de software é um trade-off
a premissa básica é que não existe “bala de prata” (silver bullet). não existe uma solução perfeita, uma arquitetura “correta” ou uma ferramenta que funcione para todos os cenários sem causar algum tipo de impacto negativo em outra ponta.
se uma decisão parece não ter um trade-off, provavelmente ele ainda não foi identificado. cada decisão técnica que se toma traz benefícios, mas invariavelmente traz custos ou desvantagens.
o trabalho do arquiteto de software não é encontrar a solução “perfeita”, mas sim determinar qual conjunto de desvantagens é mais aceitável para o contexto de negócio daquele momento.
*“se você encontrou uma solução que não tem desvantagens, você não procurou o suficiente.”
exemplos clássicos de trade-offs
monolito vs microsserviços
- monolito:
- ganhos: simplicidade de deploy; fácil de testar end-to-end; latência de rede zero entre módulos
- trade-offs: acoplamento alto; dificuldade de escalar times grandes; “single point of failure”
- microsserviços:
- ganhos: escalabilidade independente; isolamento de falhas; liberdade tecnológica por serviço
- trade-offs: complexidade operacional extrema; latência de rede; consistência de dados distribuída é difícil
consistência vs disponibilidade (teorema CAP)
em sistemas distribuídos, geralmente é preciso escolher entre garantir que todos vejam os mesmos dados ao mesmo tempo (consistência) ou garantir que o sistema responda mesmo que algumas partes estejam fora do ar (disponibilidade). isso garante resiliência, mas o contra é a complexidade na gestão dos dados.
time-to-market vs qualidade de código
a decisão de colocar em produção um código rápido, sem testes unitários robustos, garante velocidade no curto prazo, mas adquire débito técnico, que tornará a manutenção mais lenta no futuro (longo prazo).
2. o “porquê” é mais importante que o “como”
se tudo tem um lado ruim, a decisão deve ser tomada seguindo a segunda lei da arquitetura de software:” “o porquê é mais importante que o como”.
para lidar com os trade-offs, é necessário entender as características da arquitetura (ou requisitos não-funcionais) que são prioritárias para o negócio. no caso de um appfinanceiro, talvez a segurança e a consistência valham o trade-off de ser um sistema mais lento ou mais caro. em uma rede social, talvez a performance e a escalabilidade valham o trade-off de, ocasionalmente, um usuário não ver um like em tempo real (consistência eventual).
documentação de trade-offs
já que não existe solução perfeita, transparência é essencial. para registrar os trade-offs, podem ser utilizados ADRs (architecture decision records), que registram a decisão, o contexto e suas consequências.