Quando NON dovresti utilizzare i microservizi?

Question

Accepted Answer

I microservizi sono spesso la scelta **sbagliata** all'inizio. Una regola comune è **"monolite prima"**: inizia con un monolite ben strutturato ed estrai i servizi solo quando hai una ragione concreta.

## Evita i microservizi 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
```

## Il costo della divisione prematura

Spostare una chiamata a un metodo in-process a una chiamata di rete aggiunge latenza, modalità di errore, serializzazione e un'unità di distribuzione. Se i confini sono sbagliati, paghi tutto questo **e** devi comunque effettuare il refactoring tra i servizi.

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

## Percorso migliore

```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
```

## Perché è importante

La maggior parte dei team che adottano i microservizi troppo presto finisce per essere più lenta, non più veloce, perché si assume l'overhead dei sistemi distribuiti prima di averne bisogno.

Mantenere i confini all'interno di un monolite all'inizio ti permette di imparare il dominio a basso costo e dividerlo lungo le giuste fratture in seguito.