Recentemente assisti a uma entrevista com Bassem Dghaidi, engenheiro de software sênior no GitHub, falando sobre design de sistemas. O tema me chamou muita atenção porque, quanto mais estudo engenharia de software, arquitetura, backend e IA aplicada ao desenvolvimento, mais percebo uma coisa: a parte difícil não é apenas conhecer tecnologias. A parte difícil é saber quando usar, por que usar e qual problema real aquela decisão resolve.
Muita gente olha para empresas como GitHub, Google, Netflix, Uber ou Amazon e pensa: “se eles usam arquitetura distribuída, Kubernetes, filas, cache, NoSQL, sharding, feature flags e observabilidade avançada, então eu também preciso usar tudo isso no meu projeto”.
Mas talvez essa seja uma das maiores armadilhas do aprendizado em tecnologia.
O ponto mais forte da entrevista, para mim, foi este: design de sistemas não é uma competição para ver quem desenha a arquitetura mais sofisticada. É uma disciplina para tomar decisões técnicas compatíveis com o problema, a escala, o risco e o momento do negócio.
A armadilha da arquitetura por status
Uma parte da conversa fala sobre empresas que migram para Kubernetes, microsserviços ou arquiteturas cloud native não porque realmente precisam, mas porque aquilo parece moderno, bonito ou valorizado no mercado.
Isso acontece muito.
Às vezes a empresa ainda não tem escala. Às vezes o produto ainda nem validou mercado. Às vezes o time é pequeno. Às vezes o problema caberia muito bem em uma aplicação monolítica bem organizada, rodando em uma VM simples, com um banco relacional bem configurado.
Mesmo assim, a equipe decide montar uma arquitetura complexa demais.
O resultado pode ser perigoso: aumento de custo, mais pontos de falha, mais dificuldade de deploy, mais carga cognitiva para o time, mais tempo gasto mantendo infraestrutura e menos tempo entregando valor.
Existe uma frase que ficou forte para mim: o simples já é complicado o suficiente, especialmente em escala.
Essa frase resume muita coisa.
Simplicidade não é falta de conhecimento. Muitas vezes, simplicidade é justamente o resultado de maturidade. É saber que uma decisão técnica não deve ser tomada apenas porque “todo mundo está falando disso”, mas porque existe uma necessidade concreta.
Escalar antes da hora também é uma forma de desperdício
Um dos aprendizados mais importantes da entrevista foi a ideia de não projetar para uma escala imaginária de 10 anos no futuro.
É claro que precisamos pensar em evolução. Ninguém está defendendo código bagunçado, gambiarra sem critério ou ausência de arquitetura. Mas existe uma diferença enorme entre preparar um sistema para evoluir e construir hoje uma arquitetura para uma escala que talvez nunca chegue.
Muitas vezes, uma aplicação simples pode ir muito mais longe do que imaginamos. Escala vertical, uma boa modelagem de dados, bons índices, cache apenas quando necessário, observabilidade mínima e deploy bem feito já resolvem muitos problemas reais.
Antes de falar em sharding, múltiplos bancos, event streaming, microsserviços e infraestrutura distribuída, talvez a pergunta deveria ser:
qual é o gargalo real que temos hoje?
Se não existe métrica, talvez ainda não exista justificativa.
E isso muda completamente a conversa.
Em vez de “acho que precisamos de Kafka”, a discussão madura seria:
- qual problema de negócio estamos tentando resolver?
- qual volume atual?
- qual volume esperado?
- qual limite da arquitetura atual?
- qual o custo de manter a solução atual?
- qual o custo de migrar?
- qual risco operacional estamos aceitando?
- qual métrica prova que chegou a hora de mudar?
Sem esse tipo de pergunta, a arquitetura vira opinião. E opinião técnica sem contexto pode custar caro.
Software não é construído uma vez; software evolui
Outro ponto muito forte é a ideia de que software não é algo que você compra, entrega uma vez e esquece.
Muitas empresas ainda tratam software como obra fechada: paga-se uma vez, entrega-se o sistema e espera-se que ele dure anos sem investimento relevante. Mas software vive em um ambiente que muda: usuários mudam, regras mudam, mercado muda, infraestrutura muda, ameaças de segurança mudam, volume muda, dependências mudam.
Por isso, arquitetura precisa ser pensada como evolução contínua.
Não significa reescrever tudo a cada ano. Também não significa aceitar complexidade infinita. Significa revisar decisões, observar sinais, medir limites e planejar a próxima ordem de magnitude.
Essa ideia me marcou bastante: talvez a pergunta não seja “como faço uma arquitetura para durar 10 anos?”, mas sim:
qual arquitetura me leva com segurança até o próximo estágio?
Quando esse próximo estágio chegar, fazemos uma nova rodada de decisões com mais dados, mais aprendizado e mais clareza.
Resolver problema específico antes de criar solução genérica
Também gostei muito da crítica contra soluções genéricas demais.
Como desenvolvedores, é tentador criar abstrações, frameworks internos e componentes flexíveis para cenários que talvez nunca aconteçam. A intenção geralmente é boa: queremos deixar o sistema preparado para o futuro.
Mas existe um risco: quanto mais genérica uma solução fica, mais difícil pode ser entendê-la, testá-la, mantê-la e explicar suas decisões.
Resolver um problema específico primeiro tem uma vantagem enorme: você conhece melhor as restrições.
Você sabe o que importa.
Você sabe o que pode ser sacrificado.
Você sabe quais trade-offs está fazendo.
Você sabe quem é o usuário real.
Você sabe qual dor está resolvendo.
Depois, se padrões reais começarem a aparecer, aí sim pode fazer sentido extrair uma abstração.
Mas abstrair cedo demais pode virar apenas complexidade disfarçada de elegância.
Impacto de negócio importa
Outro aprendizado importante: engenharia de software profissional não é hobby.
Isso não significa abandonar o cuidado técnico. Pelo contrário. Significa entender que qualidade técnica precisa conversar com impacto real.
Não basta dizer:
“Melhorei a arquitetura.”
“Deixei o código mais limpo.”
“Criei uma infraestrutura moderna.”
“Implantei Kubernetes.”
“Adicionei cache.”
“Migrei para microsserviços.”
A pergunta mais madura é:
qual impacto isso teve?
Reduziu custo?
Aumentou confiabilidade?
Diminuiu tempo de resposta?
Reduziu incidentes?
Melhorou a experiência do usuário?
Acelerou entrega?
Reduziu risco?
Ajudou o negócio a operar melhor?
Essa parte me conecta muito com minha própria trajetória. Venho de uma área operacional, de ambiente crítico, onde decisão errada pode custar caro. Em uma operação real, não adianta ter o equipamento mais sofisticado se ele não resolve o problema no momento certo. Tecnologia, no fim, precisa servir à missão.
Na engenharia de software é parecido.
A solução mais bonita nem sempre é a solução mais adequada. Às vezes, o melhor sistema é aquele que resolve bem o problema de hoje, com segurança, clareza e espaço para evoluir.
E onde entra a IA nisso?
Esse ponto ficou ainda mais importante para mim por causa do momento atual da IA.
Com agentes de código, copilots e ferramentas cada vez mais poderosas, ficou mais fácil produzir código em grande volume. Mas isso também aumenta o risco de produzir complexidade em grande volume.
Se antes um desenvolvedor podia criar um sistema confuso em semanas, agora talvez consiga criar em horas.
Por isso, design de sistemas tende a ficar ainda mais importante. A habilidade principal não será apenas escrever código. Será saber orientar a construção, revisar decisões, entender requisitos, avaliar riscos, medir impacto e impedir que a velocidade da IA gere uma dívida técnica que ninguém consegue sustentar depois.
A IA pode acelerar muito a implementação. Mas ela não substitui responsabilidade arquitetural.
Meu principal aprendizado
Depois de assistir a essa entrevista, fiquei com uma reflexão:
um bom engenheiro não é aquele que usa a arquitetura mais avançada. É aquele que entende o problema o suficiente para escolher a solução mais apropriada.
Às vezes isso será um monólito.
Às vezes será uma VM.
Às vezes será um banco relacional.
Às vezes será cache.
Às vezes será fila.
Às vezes será microsserviço.
Às vezes será Kubernetes.
Às vezes será uma arquitetura distribuída complexa.
Mas a ordem importa.
Primeiro vem o problema.
Depois vêm as restrições.
Depois vêm as métricas.
Depois vêm os trade-offs.
Só então vem a tecnologia.
Esse é um aprendizado que quero carregar nos meus estudos e projetos: buscar fundamentos, entender contexto, evitar modismo e lembrar que software bom não é necessariamente o mais sofisticado.
Software bom é aquele que resolve o problema certo, no momento certo, com o nível certo de complexidade.
Top comments (0)