Vad är den distribuerade monolit och andra anti-mönster för mikrotjänster?

Question

Accepted Answer

Det värsta utfallet för mikrotjänster är en **"distribuerad monolitisk arkitektur"**: tjänster som är fysiskt skilda men så tätt sammankopplade att de måste distribueras tillsammans — du får all kostnad för distribution utan någon oberoende.

## Tecken på en distribuerad monolitisk arkitektur

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

## Andra vanliga anti-mönster

| Anti-mönster | Problem |
|---|---|
| Delad databas | Omkopplar tjänster; ingen oberoende schemaändring |
| Prat-intensiva tjänster | Många synkrona anrop per förfrågan → latens, skörhet |
| Nano-tjänster | För finkornig; overhead överskuggar logiken |
| Ingen API-versionering | En ändring förstör alla konsumenter |
| Synkrona kedjor | Latens och fel multipliceras längs A→B→C→D |
| Gud-tjänst | En tjänst som alla är beroende av (en ny monolitisk arkitektur) |

## Rotorsaken

Vanligtvis **felaktiga gränser**. Tjänster indelade efter tekniskt lager eller entitet (inte affärsfunktion) slutar upp chattig och ömsesidigt beroende.

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

## Varför det är viktigt

En distribuerad monolitisk arkitektur är strikt sämre än en riktig monolitisk arkitektur — långsammare, svårare att felsöka, mer att driva, men ändå omöjlig att distribuera oberoende.

De flesta anti-mönster spåras tillbaka till gränser och en delad databas, så att få rätt begränsade sammanhang och dataägandet är det som skiljer mikrotjänster som hjälper från de som skadar.

Anti-mönster	Problem
Delad databas	Omkopplar tjänster; ingen oberoende schemaändring
Prat-intensiva tjänster	Många synkrona anrop per förfrågan → latens, skörhet
Nano-tjänster	För finkornig; overhead överskuggar logiken
Ingen API-versionering	En ändring förstör alla konsumenter
Synkrona kedjor	Latens och fel multipliceras längs A→B→C→D
Gud-tjänst	En tjänst som alla är beroende av (en ny monolitisk arkitektur)