O Mito dos Microservices
Existe um mito perigoso no mundo das startups: se você quer escalar, precisa de microservices.
A lógica parece fazer sentido. Netflix usa microservices. Amazon usa microservices. Logo, microservices = escala. Certo?
Errado.
O que Netflix e Amazon não te contam é que eles começaram como monólitos. Só migraram para microservices quando sua escala (milhares de engenheiros, milhões de usuários simultâneos) tornou isso necessário.
Sistemas distribuídos são exponencialmente mais difíceis de construir, debugar e operar. Uma startup com 5 engenheiros tentando gerenciar 20 microservices é uma startup queimando runway em infraestrutura ao invés de produto.
Enter Shopify
A Shopify processa mais de 10% de todo o e-commerce dos EUA. Bilhões de dólares em transações. Sua codebase tem mais de 2.8 milhões de linhas de Ruby e 500.000 commits.
E está tudo em um repositório. Uma unidade deployável. Um modular monolith.
O Que É um Modular Monolith?
Um modular monolith é uma única codebase cuidadosamente estruturada em boundaries lógicas—componentes ou módulos—cada um cuidando de um domínio de negócio específico.
Pense como o melhor dos dois mundos:
- Simplicidade do monólito: Um repo, um deploy, um time para coordenar
- Clareza dos microservices: Boundaries claras, ownership de domínio, concerns isoladas
A Implementação da Shopify
1. Componentes como Rails Engines
Cada domínio de negócio (Checkout, Payments, Orders, Inventory, Admin) é implementado como um Rails Engine—uma mini-aplicação dentro da aplicação maior.
2. Packwerk para Enforcement de Boundaries
A Shopify construiu o Packwerk, uma ferramenta open-source que detecta automaticamente
quando um módulo tenta acessar outro módulo que não deveria.
3. Organização Orientada a Domínio
Código organizado por funcionalidade de negócio (billing, orders, inventory) ao invés de por camada técnica (controllers, models, views).
4. Ownership de Dados
Cada módulo é dono dos seus dados e expõe uma API pública. Outros módulos não podem acessar diretamente seu banco—devem passar pela API.
Quando Escolher o Quê
Comece com Monólito quando:
- Você é um time pequeno (< 20 engenheiros)
- Ainda está buscando product-market fit
- Velocidade de iteração importa mais que escala
Evolua para Modular Monolith quando:
- Seu monólito está virando "big ball of mud"
- Times estão pisando nos pés uns dos outros
- Você quer benefícios de microservices sem a complexidade
"Comece com um modular monolith. Extraia microservices apenas quando a dor for clara e específica."
— Time de Engenharia da Shopify
Pronto para Construir para Escala?
Agende uma Revisão de Arquitetura gratuita. Vamos analisar sua codebase atual e mostrar exatamente como estruturá-la para crescimento—sem o imposto dos microservices.
Obter Sua Revisão Gratuita →Conclusão
O modular monolith não é um compromisso—é uma escolha estratégica que algumas das empresas mais bem-sucedidas do mundo fizeram.
- Microservices não são necessários para escala
- Boundaries importam mais que unidades de deploy
- Comece simples, evolua deliberadamente