Quando você NÃO deve usar microserviços?

Question

Accepted Answer

Microserviços são frequentemente a **escolha errada** para começar. Uma regra comum é **"monolito primeiro"**: comece com um monolito bem estruturado e extraia serviços apenas quando tiver uma razão concreta.

## Evite microserviços quando

```text
✗ Small team — more services than people to run them
✗ Early-stage product — domain boundaries still shifting
✗ No CI/CD, monitoring, or tracing in place
✗ Low traffic — no real scaling pressure
✗ Simple domain — splitting adds cost, not value
```

## O custo da divisão prematura

Mover uma chamada de método in-process para uma chamada de rede adiciona latência, modos de falha, serialização e uma unidade de implantação. Se os limites estiverem errados, você paga tudo isso **e** ainda tem que refatorar entre serviços.

```text
method call        →  microseconds, can't fail
network call       →  milliseconds, can time out, can be down
```

## Melhor caminho

```text
Start: modular monolith (clear internal boundaries)
  └─▶ Extract a service ONLY when:
         · it needs independent scaling, OR
         · a separate team needs independent deploys, OR
         · it needs a different tech/SLA
```

## Por que isso importa

A maioria dos times que adotam microserviços muito cedo acaba mais lenta, não mais rápida, porque assumem a sobrecarga de sistemas distribuídos antes de precisarem.

Manter limites dentro de um monolito primeiro permite que você aprenda o domínio com custo baixo e divida ao longo das costuras corretas mais tarde.