Núcleo estável, periferia descartável

Fui contar o que realmente uso, em vez de responder de memória. Vinte e um projetos com pom.xml. Trinta com JPA e PostgreSQL. Quinze com TypeScript, nove com React. Python espalhado por vinte e um requirements.txt.

Olhando de fora, parece variedade. Olhando com atenção, é o oposto: existe um núcleo que não muda há dez anos e uma periferia que eu troco sem cerimônia.

A distinção entre os dois é a decisão de arquitetura que mais me economizou tempo na carreira.

O núcleo: Java, Spring, JPA, PostgreSQL

Não abro mão. E o motivo não é gosto.

Escala. Não a de gráfico de conferência — a de sistema que não pode parar, com gente real dependendo dele às duas da tarde de uma segunda-feira. A JVM tem trinta anos de trabalho investido em coletor de lixo, em modelo de memória, em comportamento sob carga. Isso não se compra com framework novo.

Aproveitamento de conhecimento. É aqui que fica interessante. No meu diretório convivem projeto em Java 8 com Spring Boot 2.1 e projeto em Java 25 com Spring Boot 3.5. São quase dez anos de distância.

O que eu aprendi depurando o primeiro continua valendo no segundo. Como o Hibernate decide carregar uma coleção. Onde a transação começa e termina de verdade. Por que aquela consulta que parecia inocente virou N+1 em produção.

Esse conhecimento é o ativo. Não a sintaxe — a sintaxe eu reaprendo numa tarde. O que não se reaprende rápido é o mapa de onde as coisas quebram.

Robustez. E aqui vale definir o termo, porque ele é usado de forma vaga.

Robusto não é "não quebra". Tudo quebra. Robusto é quebrar de um jeito que você já viu antes.

Quando o pool de conexão esgota, eu sei o que vou encontrar no log. Quando a sessão do Hibernate fecha antes da hora, eu reconheço o erro pelo formato. Não porque sou esperto — porque já apanhei disso e o comportamento não mudou entre versões.

Stack madura não entrega ausência de falha. Entrega familiaridade com a falha, que é o que permite consertar em vinte minutos em vez de uma noite.

O que eu descobri contando

Uma coisa apareceu no levantamento que eu não tinha percebido como decisão: Micrometer e Prometheus em vinte dos vinte e um projetos. Actuator em vinte e dois.

Ou seja, instrumento por padrão. Não como melhoria depois do primeiro incidente — como parte do esqueleto, junto com o starter-web.

Isso não foi escolha consciente em cada projeto. Virou reflexo, e o reflexo veio de um lugar específico: a diferença entre investigar produção com métrica e investigar sem ela é grande demais para depender de lembrança. Então virou padrão do modelo de projeto.

Vale como método: a decisão que você toma toda vez do mesmo jeito deveria estar no template, não na sua cabeça.

A periferia: escolhida por tarefa, trocada sem dó

Fora do núcleo, o critério muda completamente.

Python aparece onde eu preciso de velocidade de exploração e de ecossistema de IA — cliente HTTP, validação de dado, integração com modelo, protótipo que talvez não sobreviva ao mês. Nenhum desses códigos sustenta transação de negócio.

TypeScript com React aparece onde tem tela. Vite na maioria, e a escolha de build muda conforme o projeto sem que ninguém precise discutir.

Redis, nginx, Docker entram e saem conforme a necessidade da vez.

Isso não é descuido com a periferia. É reconhecer que ela tem custo de troca baixo. Trocar a ferramenta de build de um frontend é uma tarde. Trocar o banco de um sistema com dez anos de dado é um projeto.

O critério

O que separa núcleo de periferia não é importância. É custo de reversão.

Vale perguntar de cada peça:

Se eu quiser sair disso em três anos, o que custa?

Se a resposta for "uma tarde", escolha rápido, use o que estiver bom agora, e troque quando não estiver mais. Investir análise ali é desperdício.

Se a resposta for "reescrever metade do sistema e migrar dado histórico", então é núcleo — e núcleo se escolhe por previsibilidade de longo prazo, não por qual está melhor esta semana.

Novidade tem valor real na periferia, onde o erro é barato. No núcleo, o valor está em levar susto o menor número de vezes possível.

O lado que ninguém conta

A mesma estabilidade que protege também conserva.

Ainda tenho Java 8 e Spring Boot 2.1 rodando. Funciona. Está estável. Ninguém reclama. E é exatamente por isso que continua lá — a estabilidade que me economizou anos também removeu a pressão para migrar.

Isso é dívida técnica no formato mais silencioso: não a que dói, a que não dói. Sistema que quebra pede manutenção sozinho. Sistema que só funciona vai acumulando distância até o dia em que a migração deixa de ser incremental.

Não tenho solução elegante para isso. Tenho um hábito: revisar a idade do núcleo em intervalo fixo, mesmo sem ninguém pedindo. Se a decisão de migrar depender de alguém se incomodar, ela nunca acontece.

Resumindo

Escolher stack por projeto parece flexibilidade e costuma ser dispersão. Cada escolha nova é uma curva de aprendizado que não se soma às anteriores.

Núcleo estável, periferia descartável. O aprendizado se acumula onde importa, e a experimentação acontece onde o erro sai barato.

E a pergunta que separa os dois — quanto custa sair disso — vale mais que qualquer comparativo de benchmark.