O que é monólito distribuído e outros anti-padrões de microsserviços?

Question

IT Interview Practice · Accepted Answer

O pior resultado de microsserviços é um **"monólito distribuído"**: serviços que são fisicamente separados mas tão acoplados que devem ser implantados juntos — você obtém todos os custos da distribuição e nenhuma da independência.

## Sinais de um monólito distribuído

```text
✗ Changing one service forces redeploying several others
✗ Services share a database / shared schema
✗ A single request fans out through many synchronous hops
✗ Releases must be coordinated across teams
→ you pay network + ops cost but lost independent deployability
```

## Outros anti-padrões comuns

| Anti-padrão | Problema |
|---|---|
| Banco de dados compartilhado | Re-acopla serviços; sem mudança independente de schema |
| Serviços conversadores | Muitas chamadas síncronas por requisição → latência, fragilidade |
| Nano-serviços | Muito granular; overhead supera a lógica |
| Sem versionamento de API | Uma mudança quebra todos os consumidores |
| Cadeias síncronas | Latência e falha se multiplicam ao longo de A→B→C→D |
| Serviço god | Um serviço do qual todos dependem (um novo monólito) |

## A causa raiz

Usualmente **limites errados**. Serviços divididos por camada técnica ou entidade (não por capacidade de negócio) acabam conversadores e co-dependentes.

```text
bad:  User-svc, Product-svc, Cart-svc all called for one checkout
good: Checkout owns the capability end to end
```

## Por que isso importa

Um monólito distribuído é estritamente pior que um monólito real — mais lento, mais difícil de debugar, mais para operar, mas ainda impossível de implantar independentemente.

A maioria dos anti-padrões rastreia de volta a limites e banco de dados compartilhado, então acertar contextos limitados e propriedade de dados é o que separa microsserviços que ajudam daqueles que prejudicam.

Anti-padrão	Problema
Banco de dados compartilhado	Re-acopla serviços; sem mudança independente de schema
Serviços conversadores	Muitas chamadas síncronas por requisição → latência, fragilidade
Nano-serviços	Muito granular; overhead supera a lógica
Sem versionamento de API	Uma mudança quebra todos os consumidores
Cadeias síncronas	Latência e falha se multiplicam ao longo de A→B→C→D
Serviço god	Um serviço do qual todos dependem (um novo monólito)

Sinais de um monólito distribuído

Outros anti-padrões comuns

A causa raiz

Por que isso importa

Perguntas relacionadas