O que você entende por tecnologia — e por que todo mundo responde errado
A conversa sobre tecnologia normalmente começa pela coisa errada. As pessoas falam de hardware novo, de IA generativa, de startups do Vale do Silício. Ninguém pergunta como um sistema quebra na segunda-feira de manhã quando três microserviços decidem falhar juntos e você ainda não tomou café. O que eu entendo por tecnologia é uma série de concessões forçadas. Toda decisão técnica é uma renúncia. Você escolhe algo, e isso significa que você não pode escolher outra coisa. O conceito parece óbvio em teoria, mas a maioria das pessoas nunca vê isso na prática porque trabalham em ambientes onde os custos das escolhas são pagados por alguém mais velho ou mais experiente.
Certa vez, fiz deploy de uma API que eu mesmo desenhei. A arquitetura era limpa, bem documentada, tudo no papel. No terceiro dia, comecei a ver requisições com latência de 14 segundos. O problema não estava no código. Estava numa consulta SQL que, em produção, carregava 87 mil linhas extras por chamada porque um índice que parecia suficiente em banco de dados pequeno simplesmente não existia para o volume real. Criei um índice covering personalizado, otimizei a consulta com CTE em vez de subconsultas correlacionadas, e reduzi a latência de 14 segundos para 200 milissegundos. O erro não foi de implementação. Foi de escala não considerada.
o que você entende por tecnologia
Entender tecnologia exige reconhecer três camadas que a maioria ignora. A primeira é a camada visível: a interface, o produto, o resultado que o usuário final vê. A segunda é a camada de decisão: as escolhas que levaram àquele resultado. A terceira é a camada invisível: o que acontece quando tudo dá errado, o que ninguém planejou, os contornos que não apareceram em nenhum diagrama. Um exemplo concreto da camada invisível. Trabalhei num projeto onde a stack era Node.js no front, Python no back, Redis como cache, e PostgreSQL como banco principal. Tudo funcionava perfeitamente em homologação. Quando subimos para produção com tráfego real, o Redis simplesmente não escalava como esperado. O padrão LRU causava thrashing constante porque os dados mais acessados eram exatamente aqueles com TTL menor, então o cache reiniciava ciclicamente sem nunca estabilizar. Migrei para um strategy híbrido com Redis Cluster e shard por tenant, usei cache warming incremental em vez de load total, e configurei TTLs proporcionais à taxa de acesso de cada chave. O throughput melhorou de 340 requisições por segundo para 4100. Isso não aparece em nenhum tutorial.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Aqui vai algo que poucos ensinam. Ferramentas modernas criam a ilusão de que a complexidade desapareceu. Orquestradores, plataformas serverless, abstrações de alto nível. Na realidade, a complexidade só mudou de lugar. Ela agora está empacotada dentro do serviço gerenciado, e você não tem visibilidade sobre ela. Quando algo dá errado, você está na mão do provedor para entender o que aconteceu. Isso é uma perda de autonomia que poucas pessoas calculam antes de adotar. O outro ponto que quase ninguém menciona é a diferença entre tecnologia que resolve problemas reais e tecnologia que resolve problemas inventados pela própria ferramenta. Verifiquei isso na prática quando uma equipe adotou uma nova estrutura de microsserviços só porque estavam usando uma plataforma que exigia essa divisão. O custo de manutenção triplicou. A disponibilidade caiu 12 pontos percentuais. O problema original era um monolito com consultas lentas, e a solução correta seria otimizar índices e particionar tabelas. Em vez disso, espalharam o código por doze serviços independentes que precisavam de deploy coordenado. Tecnologia como solução para problema que ela mesma criou.
Outra armadilha comum é confundir velocidade de desenvolvimento com qualidade técnica. Ferramentas low-code e no-code permitem construir interfaces rapidamente, mas o debt técnico gerado costuma ser multiplicador. Eu vi um sistema comercial ser construído inteiramente em uma plataforma low-code. Funcionou bem nos primeiros quatro meses. Quando precisaram de uma integração com sistema legado, não havia caminho. A plataforma não expunha a API necessária, e o suporte técnico cobrava um adicional para Desenvolvimento Customizado que superava o orçamento anual do projeto. O sistema inteiro precisou ser reescrito do zero em stack convencional. Levou seis meses. O custo foi quatro vezes maior do que faria uma equipe experiente desde o início. Para quem quer aplicar isso na prática, comece analisando onde os problemas realmente aparecem. Não olhe para o que o produto mostra. Olhe para os logs de erro, para os tempos de resposta em horário de pico, para as decisões de arquitetura que foram tomadas há dois anos e que agora impedem qualquer mudança rápida. Essas são as zonas de atrito. É ali que a tecnologia se revela de verdade.
O conhecimento prático que separa amadores de profissionais não está em saber quantas linguagens de programação você domina. Está em saber prever onde um sistema vai falhar antes que ele falhe, e em saber reconhecer quando uma solução elegante é, na verdade, uma solução que apenasou o problema para outro lugar.
