Quando a tecnologia vai mal, geralmente é porque o propósito foi esquecido
Já vi muita coisa acontecer em projetos de tecnologia. A maioria dos problemas que encontrei não veio de bugs ou falhas técnicas. Veio de alguém decidir construir algo sem ter certeza do porquê. Isso acontece o tempo todo em empresas que acham que tecnologia é só uma questão de código e velocidade.
Porque todas as tecnologias são desenvolvidas com um propósito específico
O problema começa quando se pega uma solução e tenta aplicar em outro lugar sem entender a função original. Eu vi uma equipe tentar usar uma arquitetura inteira de microsserviços para um sistema que processava menos de mil requisições por dia. A justificativa era "escale bem". O sistema tinha quatro pessoas trabalhando nele e uma base de dados pequena. Era completamente desnecessário e trouxe todos os problemas de distribuição sem nenhuma das vantagens. A pergunta certa não é "o que essa tecnologia faz", mas "qual problema ela resolve que nenhum outro método resolve melhor". Se você não consegue responder isso com clareza, provavelmente não deveria estar usando aquilo.
Existe uma nuance que ninguém conta nos cursos introdutórios. Tecnologia não nasce do nada. Cada framework, biblioteca, protocolo ou ferramenta existe porque alguém teve um problema específico e as soluções disponíveis não funcionavam. O GraphQL nasceu de problemas de overfetching e underfetching no Facebook. O Rust existe porque gerenciamento manual de memória dava erro constante em produção. O Docker apareceu porque ambientes de desenvolvimento e produção não batiam. Entender a origem é mais útil do que decorar sintaxe. O erro mais comum que eu vejo é assumir que uma tecnologia nova é universalmente melhor. K8s não é melhor que um servidor simples. É apenas diferente. Para muitos casos, um servidor com um container Docker e um compose file resolve em duas horas o que em Kubernetes leva dois dias de configuração e manutenção. Eu gastei três semanas migrando um sistema pequeno para Kubernetes na primeira vez que tentei. O sistema tinha ficado perfeito rodando em um EC2. Voltei atrás e perdi um mês de produtividade. Lição aprendida.
👉 Clique no botão abaixo para saber mais sobre o assunto!
A regra prática que uso até hoje é simples. Antes de escolher qualquer ferramenta, escrevo em uma linha qual problema ela resolve, quantas pessoas serão impactadas diretamente, e qual seria o custo de não usar nada. Se a resposta for longa, o projeto ainda não está pronto para essa ferramenta. Outro ponto que gera confusão é a diferença entre propósito e propósito alcançado. Uma tecnologia pode ter sido criada para resolver X, mas na prática acabar sendo usada para Y. Eu conheço várias equipes que usam PostgreSQL como fila de mensagens porque precisavam de algo rápido e não queriam introduzir outra tecnologia no stack. Funciona. Até não funcionar, que é quando você descobre que insert massivo bloqueia leitura e seu sistema entra em colapso às três da manhã.
O caminho inverso também acontece. Às vezes a tecnologia certa é ignorada porque o propósito dela não é óbvio para quem não conhece o problema original. Em um projeto recente, precisei lidar com um processamento de dados que gerava arquivos de 40 gigabytes. O primeiro impulso foi tentar carregar tudo na memória. A solução que funcionou foi usar streaming com buffers de 5 megabytes e escrever direto no disco, sem processamento intermediário em memória. Isso reduziu o tempo de processamento de algo impraticável para cerca de onze minutos. O propósito do streaming era exatamente esse: processar volumes grandes sem exigir hardware proporcional. Se você está começando agora, esqueça a parte de "moda". Olhe para o problema. Anote o que realmente precisa ser resolvido. Depois, sim, busque ferramentas. A ordem importa e a maioria das pessoas inverte isso sem perceber.
Uma última observação prática. Tecnologia tem vida útil. Ferramentas que foram perfeitas para um propósito específico podem se tornar um problema quando esse propósito muda. Eu vi vários casos de sistemas legados que ainda rodam porque ninguém tinha coragem de remover, mesmo depois de o problema original ter desaparecido há anos. Manter tecnologia sem propósito claro é um dos maiores custos ocultos que existem em infraestrutura.
