Microservices vs. Monolito: Qual Arquitetura Escolher em 2025

O hype de microservices gerou muito sofrimento desnecessário

Entre 2015 e 2022, microservices virou sinônimo de "arquitetura moderna". Startups em fase inicial, com 3 devs e 200 usuários, construíam 15 serviços porque "é como Netflix faz". O resultado: complexidade operacional desproporcional ao tamanho do problema, infraestrutura cara e velocidade de desenvolvimento de caracol.

Em 2025, a indústria voltou a ter clareza: a arquitetura certa depende do contexto — e para a maioria dos casos, um monolito bem construído é a resposta correta.

O que são monolitos de verdade

Monolito não significa código desorganizado. Significa que a aplicação é implantada como uma unidade.

Monolito Bem Estruturado:
├── UserModule
│   ├── UserController
│   ├── UserService
│   └── UserRepository
├── OrderModule
│   ├── OrderController
│   ├── OrderService
│   └── OrderRepository
└── PaymentModule
    ├── PaymentController
    ├── PaymentService  
    └── PaymentRepository

Limites claros dentro de um único deploy.

Um monolito modular tem as vantagens de organização de microservices sem a complexidade de rede, distributed tracing e eventual consistency.

Quando microservices fazem sentido

Escala independente de partes do sistema

Se o seu módulo de busca precisa de 50 instâncias enquanto o de admin precisa de 2, faz sentido separar. No monolito, você escala tudo junto — ineficiente.

Equipes grandes com domínios distintos

Microservices cria fronteiras organizacionais. Times diferentes podem fazer deploy de seus serviços de forma independente, sem coordenação. Para times de 50+, isso é necessário.

Requis itos técnicos muito diferentes por componente

Um serviço de processamento de imagens que precisa de GPU, escrito em Python, não faz sentido no mesmo processo de uma API CRUD em Node. Aqui a separação tem justificativa técnica real.

Workloads com picos muito distintos

Processamento de pagamentos, envio de e-mails, processamento de dados históricos — cada um tem padrão de carga diferente e políticas de escala diferentes.

Quando microservices NÃO fazem sentido

• Time pequeno (< 10 devs)
• Produto em fase de descoberta (o domínio ainda está mudando)
• Sem infraestrutura madura (não tem Kubernetes, service mesh, observabilidade)
• Quando a complexidade de negócio não justifica a complexidade técnica

A regra de Amazon (famosa "two pizza rule") é frequentemente mal aplicada: era sobre autonomia de time, não sobre tamanho de serviço.

Os problemas reais de microservices que ninguém fala em talk de conferência

Latência de rede entre serviços

Uma chamada de função local leva nanosegundos. Uma chamada HTTP entre serviços leva milissegundos. Em um fluxo com 10 serviços em sequência, isso acumula.

Eventual consistency é difícil

Com dados em múltiplos serviços, transações distribuídas são complexas. O pattern Saga resolve, mas adiciona muito código e raciocínio:

Pedido criado → Reservar estoque → Cobrar pagamento → Confirmar pedido

Se pagamento falha → Liberar estoque → Cancelar pedido

Cada compensação precisa ser idempotente e tolerante a falhas.

Debugging distribuído

"A ordem não foi processada" — onde está a falha? No serviço de pedidos? De estoque? De pagamento? De notificação? Sem distributed tracing (Jaeger, Zipkin, Honeycomb), o debugging é uma cacofonia de logs em sistemas diferentes.

Deploy hell sem disciplina

Versionar contratos de API entre serviços, gerenciar mígrações coordenadas, garantir compatibilidade retroativa — tudo isso é custo operacional real.

O Modular Monolith: o melhor dos dois mundos

// Separação de domínios clara, deploy unificado
// packages/orders/src/OrderService.ts
export class OrderService {
  constructor(
    private readonly orderRepository: OrderRepository,
    // Interface — não acoplamento direto ao serviço de pagamento
    private readonly paymentPort: PaymentPort,
    private readonly inventoryPort: InventoryPort,
  ) {}
}

Com ports-and-adapters (hexagonal architecture), você consegue separar domínios sem precisar de rede entre eles. Se um dia precisar extrair um módulo para serviço separado, a fronteira já está desenhada.

A sequência correta de evolução

1. Comece monolito modular: entregue rápido, aprenda o domínio
2. Extraia quando houver justificativa clara: escala, time, requerimento técnico distinto
3. Invista em observabilidade antes de distribuir: logs, métricas, traces desde o monolito
4. Nunca distribua um big ball of mud: limpe antes de separar

Conclusão

Microservices não é evolução natural de monolito — é uma escolha arquitetural com trade-offs específicos. Para a maioria das empresas em crescimento, um monolito modular bem estruturado é mais seguro, mais rápido de desenvolver e mais simples de operar. Reserve microservices para quando você tiver problemas que só microservices resolvem.