Monolito ou microsserviços: qual arquitetura escolher?

A arquitetura define como o sistema é organizado por dentro, e isso afeta custo, velocidade de entrega e capacidade de crescer. Duas opções aparecem em quase toda conversa: o monolito, que reúne tudo em uma aplicação, e os microsserviços, que dividem o sistema em partes independentes.

Resposta rápida

Para a maioria dos produtos novos, comece com um monolito bem organizado (monolito modular). Migre para microsserviços apenas quando existirem motivos concretos: times grandes que se atrapalham, partes do sistema com demandas de escala muito diferentes ou necessidade de implantar partes de forma independente.

O que é um monolito

Um monolito é uma aplicação única, publicada como uma unidade. Interface, regras de negócio e acesso a dados vivem no mesmo código. É mais simples de desenvolver, testar e publicar, e costuma ser mais barato no início.

O que são microsserviços

Nos microsserviços, o sistema é dividido em serviços pequenos, cada um responsável por uma parte do negócio (por exemplo, pagamentos, cadastro e notificações). Cada serviço pode ser desenvolvido, publicado e escalado separadamente, e eles conversam por APIs, filas ou webhooks.

Comparativo

O meio-termo: monolito modular

Um monolito modular mantém uma aplicação única, mas organiza o código em módulos com fronteiras claras. Você ganha a simplicidade operacional do monolito e deixa o caminho aberto para extrair um módulo como serviço no futuro, se fizer sentido.

Quando faz sentido migrar para microsserviços

• vários times mexem no mesmo código e se atrapalham nas publicações;
• uma parte do sistema recebe carga muito maior que o resto e precisa escalar sozinha;
• partes diferentes exigem tecnologias ou níveis de disponibilidade distintos;
• a empresa já tem maturidade em automação de publicação, monitoramento e operação.

Se nenhum desses pontos se aplica, a migração tende a trazer mais custo do que benefício.

Erros comuns

• adotar microsserviços "porque grandes empresas usam", sem ter o mesmo problema;
• dividir cedo demais, antes de entender as fronteiras do negócio;
• criar serviços que dependem uns dos outros o tempo todo (um "monolito distribuído");
• ignorar monitoramento e logs, essenciais em sistemas distribuídos.

E para sistemas corporativos?

Em sistemas de grande porte, com muitos times, integrações com legados e exigências de disponibilidade, microsserviços costumam fazer parte da solução. Veja como isso entra em software corporativo enterprise. Se o sistema atual já é um monolito antigo e difícil de manter, leia sobre modernização de sistemas legados.

Perguntas frequentes

Microsserviços são melhores que monolito?

Não em geral. São mais adequados a problemas de escala e organização de times grandes. Para a maioria dos produtos novos, o monolito é mais rápido e barato.

Posso começar com monolito e migrar depois?

Sim, e é o caminho mais comum. Um monolito modular facilita essa migração.

Microsserviços custam mais?

Normalmente sim, pela infraestrutura, o monitoramento e a complexidade de operação. O custo só compensa quando há ganho real de escala ou de autonomia dos times.

Qual a melhor arquitetura para um MVP?

Um monolito simples ou modular, para lançar rápido e aprender. Veja desenvolvimento de MVP.

Conclusão

Arquitetura é decisão de negócio. Comece simples, organize bem o código e divida o sistema quando houver um motivo mensurável para isso.