Ensaios opinativos sobre engenharia de software. Textos longos, sem hype.
Serverless virou poster de hype, mas pouca gente fala do estouro de faturamento e da latência imprevisível que detonam projetos no mundo real. Neste artigo direto das trincheiras, explico por que muitos times caem na armadilha, quando serverless realmente faz sentido e como evitar que sua conta na nuvem vire um monstro enquanto o usuário espera frio por uma resposta.
Quando a comunicação entre microserviços vira uma roleta russa, não é por falta de tecnologia — é por falta de contrato claro, confiança e maturidade arquitetural. Esse artigo vai direto na ferida: integrações frágeis, protocolos mal escolhidos, retries virando gambiarra e um ecossistema que deveria ser desacoplado, mas que depende de 'promessas' que nunca se cumprem. Aqui é trincheira, não palestra de conferência. Vamos colocar ordem no caos.
Kubernetes virou o novo martelo universal. Só que, na trincheira, muita equipe descobre tarde demais que o cluster não escala o negócio — escala a complexidade. Aqui eu explico, sem gourmetização, por que o Kubernetes pode virar o maior gargalo da arquitetura e como desenroscar isso com pragmatismo, contexto de negócio e foco real em fluxo. Não é um manifesto anti-K8s — é um alerta para quem já sangrou com o hype.
Microserviços viraram martelo para todo prego corporativo, mas a maioria dos times se queima exatamente tentando ser ‘simples’. A verdade é dura: simplicidade em microserviços não tem nada de simples. Exige disciplina, renúncia e entender o contexto de negócio antes de começar a quebrar sistemas. Neste artigo, destrincho a ilusão da simplicidade mágica, exponho onde os times tropeçam e mostro um caminho pragmático — direto das trincheiras — para quem quer microserviços sem cair no abismo do over-engineering.
Muita gente acha que NestJS é a bala de prata do backend em Node, mas na trincheira a história é outra. Em projetos de médio porte, ele costuma virar um arcabouço pesado, cheio de abstrações desnecessárias e difícil de manter. Neste artigo eu — Rei Nascimento — destrincho onde o hype quebra, por que ele infla dívida técnica e quando você deveria pular fora antes que o framework vire o projeto.
Kubernetes virou o canivete suíço da moda, mas isso não significa que ele resolve seus problemas — muitas vezes, só os camufla. Este artigo é para quem já sentiu na pele o peso de manter um cluster que virou um castelo grego para rodar meia dúzia de serviços. Aqui eu destrincho onde o hype deixa rombos, quando faz sentido usar, como aplico na prática e quais dívidas técnicas você está assumindo sem perceber.
Código sujo não é um detalhe estético: é um imposto eterno que cresce a cada sprint. Quando ignoramos legibilidade em sistemas complexos, criamos um terreno minado onde tudo quebra, nada evolui e a equipe inteira paga juros altíssimos de dívida técnica. Como Arquiteto que já lidou com heranças de terror, explico aqui — sem gourmetização — como legibilidade deixa de ser frescura e vira questão de sobrevivência.
O Event Loop virou aquele “monstro do armário” que todo dev jura que entende, mas na hora do vamos ver trava o sistema com um `await` mal colocado. Neste artigo eu destrincho, sem gourmetização, por que o Event Loop virou mito clássico, onde ele realmente queima projetos e como usar DDD para não transformar um problema de I/O em caos arquitetural. É direto, pragmático e sem idolatrar hype.
Eventos assíncronos no Node.js são poderosos, mas também um terreno minado. Já vi muita aplicação virar um monstro difícil de depurar por causa de chain de callbacks, listeners ocultos e filas que crescem até explodir a memória. Neste artigo, assumo o lado direto e pragmático: explicar onde a coisa dá errado, como evitar over-engineering e mostrar uma implementação madura que não vira dívida técnica amanhã.
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.