Pockit
Back

Adeus Hype de Microsserviços: O Retorno Triunfal do Monolito Modular em 2025

Vamos ser sinceros. Nos últimos 10 anos, se você não falasse "Microsserviços" numa entrevista de System Design, você nem passava da triagem.

Vimos startups com meia dúzia de devs subindo clusters de Kubernetes antes mesmo de ter o first commit direito. Pegavam uma lógica de 500 linhas e quebravam em seis serviços. Era a era de ouro do "Resume Driven Development" (Desenvolvimento Orientado ao LinkedIn).

Mas em 2025, o jogo virou. O Amazon Prime Video economizou uma fortuna voltando pro monolito. O DHH (criador do Rails) continua pregando a "Majestade do Monolito".

A ficha caiu:
"Microsserviços são uma dívida técnica com juros de agiota, e a maioria dos times não tem caixa pra pagar."

Calma, não estou falando que microsserviços não prestam. Mas perdemos a mão. Neste post, vamos entender "o que devs estão realmente buscando" e por que o "Monolito Modular" é a arquitetura sã que você deveria estar construindo.

A Grande Mentira do "Desacoplamento"

O papo de vendedor era lindo: "Desacople tudo! Se o serviço A cair, o B continua de pé! Times independentes!"

Na teoria, lindo. Na prática, a galera construiu foi um Monolito Distribuído. E isso é o pior dos dois mundos.

1. Você não desacoplou, só botou latência no meio

Se pra renderizar a home você precisa chamar o User Service, que chama o Auth Service, que chama o DB Service... meu amigo, isso tá acoplado até o pescoço.

A diferença é que no monolito, se você mudasse uma função, a IDE te avisava na hora (Type Check). Agora, uma mudança no JSON do serviço C quebra o serviço A em produção, e você só descobre quando o cliente reclama. O refatoramento que levava 1 minuto agora exige reunião entre três squads.

2. O Pedágio de Rede

Num monolito, chamar função é de graça (nanossegundos).
Em microsserviços, cada interação paga pedágio:

  1. Serializar JSON (Gasta CPU)
  2. Viagem pela rede (Latência)
  3. Load Balancer (Mais latência)
  4. Deserializar (Gasta CPU)
  5. Executar
  6. ...e volta tudo.

Já vi login fazendo 50 requests internos. Isso não é "Web Scale", isso é só queimar dinheiro da AWS à toa.

O Pesadelo de Ops

"Na minha máquina funciona". É, mas agora sua "máquina" precisa subir 15 containers Docker via docker-compose e seu notebook parece que vai decolar de tanto que a ventoinha gira.

  • Cadê o erro?: Antes era só dar um grep no log. Agora você precisa de Jaeger, Zipkin ou pagar uma nota pro Datadog só pra saber onde a request morreu.
  • Adeus Transações: Esquece o bom e velho BEGIN... COMMIT. Bem-vindo ao inferno da Consistência Eventual e Saga Pattern. Você vai passar mais tempo codando "logica de compensação" (o que fazer se der erro no meio) do que a feature em si.

A Solução: Monolito Modular

Então voltamos pro código espaguete de 2012? Aquele server.js de 5GB? Nem a pau.

A resposta é o Monolito Modular.
Fisicamente é um único artefato (um repo, um deploy). Logicamente é separado como microsserviços.

As Regras do Jogo

  1. Um Deploy Só: CI/CD trivial. Um binário/container.
  2. Comunicação em Memória: Nada de HTTP interno. Chamada de método tipado. Rápido e seguro.
  3. Muros Altos: O módulo de Pedidos NÃO PODE importar models do módulo de Usuários. Proibido.

Como fica no código

Em Node.js/TS, você força isso com Nx, Turborepo ou ESLint no-restricted-imports.

src/
  modules/
    users/
      index.ts      # (PÚBLICO) Só exporta interfaces e services fachada
      core/         # (PRIVADO) Toda a lógica suja fica aqui
      db/           # (PRIVADO) Ninguém de fora toca nisso
    orders/
      ...
  shared/           # O mínimo necessário (logs, date utils)
  app.ts            # A cola que junta tudo

Se você tentar fazer import User from '../users/db/User', o linter tem que bater na sua mão. A arquitetura se mantêm no código, não no diagrama do Confluence que ninguém lê.

Quando usar Microsserviços de verdade?

Eles não morreram, só não devem ser o default. Use quando:

  1. Escala de Pessoas, não de Tráfego: Você tem 100+ devs backend. O merge hell num repo só tá insuportável. Aí sim, você paga o preço técnico pra ganhar agilidade organizacional.
  2. Poliglota por necessidade: Um módulo precisa de GPU e Python pra IA, o resto é CRUD em Node. Separa.
  3. O "Vizinho Barulhento": Uma feature específica tem picos bizarros de tráfego que derrubam o servidor todo. Isola ela.

Conclusão: Menos Hype, Mais Entrega

Design de sistemas é sobre escolher quais problemas você quer ter.
Microsserviços troca problemas de código por problemas de sistemas distribuídos. Pra 99% dos projetos, é uma troca burra.

Em 2025, ser Sênior de verdade é ter a coragem de dizer "Não, vamos fazer simples".
Monta um Monolito Modular bem feito. Durma tranquilo. E se um dia você tiver o "bom problema" de ter 100 milhões de usuários, aí você quebra.

O "Boring" (chato) é o que dá lucro.

System DesignArchitectureMicroservicesBackendDevOps