Tradeoffs de arquitetura de software: onde a complexidade vai morar

Todo desenho de arquitetura parece razoável quando ainda está no slide. A dificuldade começa quando o sistema precisa ser operado, observado, depurado e mudado por gente real. É aí que os tradeoffs de arquitetura de software em produção deixam de ser uma discussão estética e viram custo operacional.

A ideia central é simples: arquitetura não elimina complexidade. Ela só muda o lugar onde essa complexidade aparece.

Complexidade não desaparece

Fred Brooks separou a complexidade essencial, que vem do próprio problema, da complexidade acidental, que nasce das escolhas feitas para implementar a solução. Essa distinção continua útil porque impede uma ilusão comum: acreditar que uma arquitetura nova vai apagar o problema em vez de deslocar o custo.

John Ousterhout trata complexidade como o centro do design de software. Dependências difíceis de enxergar, interfaces confusas e comportamento implícito tornam o sistema caro de entender e modificar. Esse custo não fica parado. Quando você tenta simplificar uma parte, ele costuma reaparecer em outra.

A Lei de Conservação da Complexidade, associada a Larry Tesler, resume bem essa intuição. Todo sistema tem uma parcela de complexidade que alguém precisa pagar. Pode ser o desenvolvedor, o time de plataforma, a infraestrutura, o operador em incidente ou o usuário final. Arquitetura é decidir quem paga, quando paga e com que ferramentas.

Tradeoffs de arquitetura de software em produção

Na prática, a complexidade costuma se mover entre alguns eixos conhecidos: código, rede, dados, deploy, observabilidade, custo e time.

Microserviços podem reduzir acoplamento de código e permitir deploy independente. Em troca, colocam pressão em contratos, latência, retries, timeouts, idempotência e tracing distribuído. Serverless tira do time parte da gestão de servidor, mas cobra em limites de plataforma, cold start, empacotamento, observabilidade e modelo de cobrança. Monólito evita muita coordenação distribuída, mas concentra mudança, deploy e fronteiras internas no mesmo artefato.

Nenhuma dessas escolhas é moralmente superior. A pergunta madura não é “qual arquitetura é melhor?”. A pergunta é: em qual eixo o seu time consegue carregar a complexidade sem quebrar produção?

Três casos mostram a mecânica

O caso do Prime Video é útil justamente porque foi lido de forma errada. O pipeline de Video Quality Analysis usava Step Functions, Lambda e S3 entre etapas. Em um workload intensivo em dados, o tráfego entre componentes virou custo dominante. A migração para um processo único no ECS reduziu custo em cerca de 90%. Isso não prova que microserviços falharam. Prova que aquele desenho colocou complexidade no eixo errado para aquele tipo de carga.

Na Segment, a empresa chegou a mais de 140 serviços para gerenciar integrações. A intenção era isolar responsabilidades. O preço apareceu no time: cada integração nova exigia mais provisionamento, mais pipeline, mais operação. A consolidação em um monólito restaurou velocidade. Não foi uma vitória abstrata do monólito. Foi uma correção de custo cognitivo e operacional.

Shopify mostra outro caminho. A empresa opera um grande monólito Rails, mas precisou impor fronteiras internas para evitar que qualquer parte do sistema dependesse de qualquer outra. O Packwerk entra nesse contexto: modularidade dentro do monólito, com disciplina explícita de dependências.

Nos três casos, a primeira arquitetura otimizava algum eixo. Depois, o contexto mudou ou a escala cobrou a conta em outro lugar.

Decisão arquitetural precisa ser revisável

Uma decisão boa em arquitetura não é a que parece moderna. É a que deixa claro o preço aceito. “Estamos aceitando mais complexidade de rede para ganhar autonomia de deploy.” “Estamos aceitando deploy compartilhado para reduzir coordenação distribuída.” Se a frase não fecha, provavelmente a equipe está copiando uma arquitetura sem entender o tradeoff.

Também vale mapear a capacidade real do time. Arquitetura que depende de observabilidade madura, mas roda em uma organização sem tracing confiável, está financiando incidente futuro. Arquitetura que exige ownership claro, mas opera em uma estrutura confusa, vai cobrar em filas, handoffs e retrabalho.

Produção não premia desenho elegante. Premia decisão que o time consegue operar quando a abstração falha.

Referências

Assista ao vídeo completo no YouTube →

Leia também