Ensaios opinativos sobre engenharia de software. Textos longos, sem hype.
Reatividade demais vira passivo. No frontend moderno, o hype de ‘tudo precisa reagir a tudo’ criou interfaces frágeis, lentas e difíceis de manter. Como arquiteto que já viu SPA colapsando por excesso de watchers, signals mal usados e stores replicados sem critério, este artigo corta o ruído e entrega o que realmente importa: como evitar a reatividade excessiva e construir UIs que não desmoronam no primeiro pico de uso.
Microserviço virou moda, virou mantra, virou hype… e virou dor. Depois de ver time quebrando sprint por causa de pipelines monstruosos, deploy orquestrado que mais parece ritual xamânico e bugs que viajam por 12 serviços antes de aparecer, escrevo aqui a visão nua e crua de quem já comeu poeira suficiente nas trincheiras para separar arquitetura de palco de arquitetura de produção.
Muita gente ainda acha que monolito é sinônimo de simplicidade e microservices é hype. A realidade nas trincheiras é bem menos romântica: ambos podem virar um inferno caro se escolhidos fora do contexto de negócio. Neste artigo eu abro o jogo, sem gourmetização, mostrando por que microservices fazem sentido em algumas arquiteturas — e por que o “monolito simples” frequentemente vira uma bola de neve de dívida técnica.
Quando o assunto é escalar uma plataforma, muita gente trava no dilema REST vs GraphQL — e boa parte dessa trava vem de hype, não de necessidade real. Aqui eu, Rei Nascimento, corto o excesso, foco no que importa e mostro como essa escolha pode gerar dívida técnica ou salvar sua arquitetura. Direto das trincheiras, sem poesia arquitetural.
Microserviços viraram religião. E, como toda religião mal interpretada, criou fanático achando que qualquer API com três rotas já merece dez serviços, quatro filas e um diagrama que parece um ninho de marimbondo. Neste artigo, falo direto da trincheira: quando microserviços viram over‑engineering, como isso destrói produtividade e por que a obsessão pelo hype cria monólitos mentais — mesmo quando o código está “distribuído”. Sem firula, só pragmatismo.
Kubernetes virou sinônimo de “arquitetura moderna”, mas para novas aplicações que precisam entregar valor rápido, ele tem sido mais âncora do que propulsor. O excesso de camadas, YAML infinito e carga operacional transformam algo simples em uma caricatura de complexidade. Aqui eu explico, sem floreio, por que muitos times estão usando Kubernetes como muleta arquitetural — e como evitar cair nessa armadilha que só aumenta dívida técnica e mata agilidade.
Muita gente veste Kafka como se fosse armadura de resiliência e escalabilidade. Mas quando o contexto de negócio não pede, o hype vira dívida técnica. Aqui eu bato direto no ponto: microserviços não ficam magicamente resilientes só porque você jogou um Kafka no meio. Vamos destrinchar onde o dev se queima, quando Kafka realmente resolve e quando ele só adiciona latência, custos e uma bela dor de cabeça operacional.
MongoDB é rápido de colocar no ar, flexível e ótimo para protótipos. Mas quando o jogo é sério — missão crítica, consistência, auditoria, garantias duras — ele começa a cobrar juros altos de dívida técnica. Como arquiteto que vive nas trincheiras, escrevo aqui o que quase ninguém fala: o risco não é usar MongoDB; o risco é usá‑lo sem entender o preço real.
Microserviço não é salvador da pátria — é ferramenta. E, como qualquer ferramenta, corta dos dois lados. Depois de anos nas trincheiras vendo sistemas virarem Frankensteins distribuídos, fica claro: o microserviço perfeito não existe porque o negócio real não é perfeito. Neste artigo, mostro onde os devs se queimam, como evitar a gourmetização arquitetural e quando reduzir complexidade vale mais do que ficar perseguindo um ideal técnico que só existe em conference talk.
Velocidade sem qualidade é só combustível pro retrabalho. Neste artigo eu destrincho, sem gourmetização, o paradoxo que assombra times ágeis: entregar rápido sem transformar o backlog em um cemitério de bugs e dívidas técnicas. Como arquiteto nas trincheiras, explico por que agilidade não é sinônimo de pressa e mostro práticas reais — nada de hype — para estabilizar fluxo, proteger qualidade e parar de brincar de apostar contra a própria equipe.