Microsserviços vs Monolith: tomando a decisão correta de arquitetura

72% das empresas que adotaram microsserviços prematuramente relatam aumento de complexidade sem benefícios proporcionais. O entusiasmo pelos microsserviços levou muitas equipes a distribuir seus aplicativos por dezenas de serviços, quando um monólito bem estruturado as teria atendido melhor, mais rápido e mais barato.

Este guia fornece uma estrutura honesta para escolher entre arquiteturas monolíticas e de microsserviços, incluindo as abordagens híbridas que geralmente fazem mais sentido para empresas em crescimento.

Principais conclusões

• Comece com um monólito, a menos que você tenha uma necessidade específica e comprovada de escalonamento ou implantação independente
• O tamanho da equipe é o indicador mais forte do sucesso dos microsserviços: mínimo de 3 engenheiros por serviço
• O padrão "monólito modular" oferece a maioria dos benefícios de microsserviços sem sobrecarga operacional
• A migração do monolith para microsserviços deve ser incremental, extraindo um serviço por vez

---

A comparação honesta

Vantagens do Monólito

Vantagens dos microsserviços

Custos de microsserviços (frequentemente subestimados)

---

A Estrutura de Decisão

Decisão por tamanho da equipe

Decisão por Necessidades de Dimensionamento

Decisão por necessidades de implantação

---

O monólito modular: o melhor dos dois mundos

Um monólito modular organiza o código em módulos bem delimitados em uma única unidade implantável. Os módulos se comunicam por meio de interfaces definidas, não por acesso direto ao banco de dados.

Arquitetura

Single Deployment Unit
+---------------------------------------------------+
|  [Orders Module]  [Inventory Module]  [Users Module] |
|       |                  |                 |        |
|       +------ Internal API Layer ----------+        |
|       |                  |                 |        |
|  [Orders DB]   [Inventory DB]    [Users DB]          |
|       |                  |                 |        |
|       +------ Shared Database Server ------+        |
+---------------------------------------------------+

Padrão Monólito Modular NestJS

// orders/orders.module.ts
@Module({
  imports: [
    InventoryModule, // Explicit dependency declaration
    UsersModule,
  ],
  controllers: [OrdersController],
  providers: [OrdersService],
  exports: [OrdersService], // Controlled public interface
})
export class OrdersModule {}

// inventory/inventory.module.ts
@Module({
  controllers: [InventoryController],
  providers: [InventoryService],
  exports: [InventoryService], // Only expose what others need
})
export class InventoryModule {}

Regras do módulo:

1. Os módulos comunicam-se através de serviços exportados, nunca através de acesso direto ao banco de dados
2. Cada módulo possui exclusivamente suas tabelas de banco de dados
3. Os dados compartilhados são acessados através de métodos de serviço, não de JOINs através dos limites do módulo
4. As dependências do módulo são explícitas na matriz imports

Quando extrair um módulo para um serviço

Extraia quando:

• O módulo precisa ser dimensionado de forma independente (por exemplo, processamento de imagem, pesquisa)
• A frequência de implantação do módulo difere significativamente do resto
• O módulo é mantido por uma equipe separada
• O módulo possui diferentes requisitos tecnológicos (por exemplo, modelo ML em Python)

NÃO extraia quando:

• "Parece que deveria ser um serviço"
• Você quer uma arquitetura mais limpa (em vez disso, refatore o monólito)
• Você não identificou uma necessidade específica de escalonamento ou implantação

---

Estratégia de migração: Monolith para microsserviços

O padrão do figo estrangulador

Substitua gradualmente a funcionalidade monolítica por microsserviços, roteando o tráfego para o novo serviço enquanto o código antigo permanece como substituto.

Etapa 1: Identifique o candidato à extração (maior necessidade de escalonamento ou atrito de implantação)

Etapa 2: Crie o novo serviço junto com o monólito

Etapa 3: rotear o tráfego para o novo serviço por meio do gateway de API

Etapa 4: verifique a correção executando ambos em paralelo

Etapa 5: Remova o código antigo do monólito

Considerações sobre migração de dados

Recomendação: comece com um banco de dados compartilhado durante a migração e, em seguida, passe para o banco de dados por serviço assim que os limites do serviço forem comprovados.

---

Exemplos de arquitetura do mundo real

Plataforma de comércio eletrônico

Modular Monolith (recommended for most):
- Product catalog module
- Cart and checkout module
- Order management module
- User accounts module
- Inventory module
All in one deployable unit, backed by one PostgreSQL instance.

Selective Microservices (for high-traffic stores):
- Search service (Elasticsearch, scales independently)
- Image processing service (CPU-intensive, different scaling)
- Payment service (PCI compliance boundary)
Everything else stays in the monolith.

Sistema ERP (estilo Odoo)

Monolith is the correct choice for ERP:
- Deep cross-module data relationships
- Complex business rules spanning modules
- Consistent reporting across all data
- Smaller concurrent user counts
- Transactional consistency critical

Odoo itself is a modular monolith: modules are installed/uninstalled,
but everything runs in one process with one database.

---

Perguntas frequentes

Nosso monólito está nos impedindo?

Provavelmente não, a menos que você tenha evidências de gargalos específicos. Se as implantações forem lentas, invista em CI/CD. Se um componente precisar ser dimensionado, extraia-o. Se as equipes estiverem se atropelando, imponha os limites do módulo. A maioria dos “problemas monolíticos” são, na verdade, problemas de organização de código que os microsserviços não resolveriam – eles apenas os distribuiriam.

Quantos microsserviços são demais?

Um limite prático: não mais que 3-5 serviços por engenheiro responsável pelas operações. Uma equipe de 5 engenheiros não deve possuir mais do que 15 a 25 serviços. Além disso, a sobrecarga operacional domina e a velocidade de engenharia cai. Muitas empresas de sucesso executam de 5 a 10 serviços bem definidos, em vez de centenas de nanosserviços.

Podemos usar bancos de dados diferentes para módulos diferentes em um monólito?

Sim, esta é a abordagem modular monolítica. Cada módulo pode usar um esquema separado ou até mesmo uma instância de banco de dados separada na mesma unidade implantável. Isto preserva os limites de propriedade dos dados sem o custo operacional de serviços separados. Também facilita a extração futura.

Como a ECOSIRE aborda isso para os clientes?

Recomendamos começar com um monólito modular para a maioria dos clientes. Nossos serviços de implementação Odoo usam a arquitetura modular do Odoo, e nossos projetos de desenvolvimento personalizados seguem o padrão monólito modular NestJS. Extraímos serviços apenas quando há necessidade comprovada de escalonamento independente – normalmente pesquisa, processamento de arquivos ou integrações externas. Consulte nosso guia DevOps para conhecer a filosofia arquitetônica completa.

---

O que vem a seguir

As decisões de arquitetura são fundamentais. Depois de escolher sua abordagem, invista em automação de CI/CD para implantação confiável, monitoramento para visibilidade operacional e padrões de gateway de API para gerenciar a comunicação entre serviços.

Contate a ECOSIRE para consultoria de arquitetura ou explore nossos serviços de implementação Odoo para arquitetura de ERP que se adapta ao seu negócio.

---

Publicado pela ECOSIRE – ajudando as empresas a escolher a arquitetura certa para seu estágio de crescimento.