Cos'è il distributed monolith e altri anti-pattern nei microservizi?

Question

Accepted Answer

Il risultato peggiore dei microservizi è il **"distributed monolith"**: servizi fisicamente separati ma così fortemente accoppiati che devono essere deployati insieme — ottieni tutti i costi della distribuzione e nessuna dell'indipendenza.

## Segni di un distributed monolith

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

## Altri anti-pattern comuni

| Anti-pattern | Problema |
|---|---|
| Shared database | Ricrea accoppiamento tra servizi; nessun cambio di schema indipendente |
| Chatty services | Molte chiamate sync per request → latenza, fragilità |
| Nano-services | Troppo granulari; l'overhead supera la logica |
| No API versioning | Un cambio rompe ogni consumer |
| Synchronous chains | Latenza e fallimenti si moltiplicano lungo A→B→C→D |
| God service | Un servizio da cui tutti dipendono (un nuovo monolith) |

## La causa radice

Solitamente **boundary sbagliati**. Servizi divisi per layer tecnico o entità (non per business capability) finiscono per essere chatty e co-dipendenti.

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

## Perché è importante

Un distributed monolith è rigorosamente peggiore di un vero monolith — più lento, più difficile da debuggare, più da operare, eppure ancora impossibile da deployare indipendentemente.

Most anti-pattern risalgono a boundary e shared database, quindi ottenere bounded context e data ownership corretti è ciò che distingue i microservizi che aiutano da quelli che danneggiano.

Anti-pattern	Problema
Shared database	Ricrea accoppiamento tra servizi; nessun cambio di schema indipendente
Chatty services	Molte chiamate sync per request → latenza, fragilità
Nano-services	Troppo granulari; l'overhead supera la logica
No API versioning	Un cambio rompe ogni consumer
Synchronous chains	Latenza e fallimenti si moltiplicano lungo A→B→C→D
God service	Un servizio da cui tutti dipendono (un nuovo monolith)