Hvad er den distribuerede monolitisk arkitektur og andre anti-patterns for mikroservices?

Question

Accepted Answer

Det værste resultat af mikroservices er en **"distribueret monolith"**: tjenester, der er fysisk adskilt, men så tæt koblet, at de skal installeres sammen — du får alle omkostningerne ved distribution uden nogen uafhængighed.

## Tegn på en distribueret 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
```

## Andre almindelige anti-patterns

| Anti-pattern | Problem |
|---|---|
| Delt database | Genkoblet tjenester; ingen uafhængig skemaændring |
| Sludder-tjenester | Mange synkrone kald pr. anmodning → latens, skørhed |
| Nano-tjenester | For finkornet; overhead overskygger logikken |
| Ingen API-versionering | En ændring ødelægger alle forbrugere |
| Synkrone kæder | Latens og fejl multipliceres langs A→B→C→D |
| Gud-tjeneste | En tjeneste som alle afhænger af (en ny monolith) |

## Grundårsagen

Normalt **forkerte grænser**. Tjenester opdelt efter teknisk lag eller enhed (ikke forretningskapabilitet) ender med at være sludder og gensidigt afhængige.

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

## Hvorfor det betyder noget

En distribueret monolith er strengt værre end en rigtig monolith — langsommere, sværere at debugge, mere at drive, og alligevel umulig at installere uafhængigt.

De fleste anti-patterns stammer fra grænser og en delt database, så at få bounded contexts og dataejerskap rigtigt er det, der adskiller mikroservices, der hjælper, fra dem der skadar.

Anti-pattern	Problem
Delt database	Genkoblet tjenester; ingen uafhængig skemaændring
Sludder-tjenester	Mange synkrone kald pr. anmodning → latens, skørhed
Nano-tjenester	For finkornet; overhead overskygger logikken
Ingen API-versionering	En ændring ødelægger alle forbrugere
Synkrone kæder	Latens og fejl multipliceres langs A→B→C→D
Gud-tjeneste	En tjeneste som alle afhænger af (en ny monolith)