Wann sollten Sie Microservices NICHT verwenden?

Question

Accepted Answer

Microservices sind oft die **falsche** Ausgangswahl. Eine häufige Regel ist **"Monolith zuerst"**: Beginnen Sie mit einem gut strukturierten Monolithen und extrahieren Sie Dienste nur dann, wenn Sie einen konkreten Grund haben.

## Vermeiden Sie Microservices, wenn

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

## Die Kosten der vorzeitigen Aufteilung

Das Verschieben eines In-Process-Methodenaufrufs zu einem Netzwerkaufruf fügt Latenz, Fehlermodi, Serialisierung und eine Deployment-Unit hinzu. Wenn die Grenzen falsch sind, zahlen Sie alles das **und** müssen trotzdem noch über Services hinweg refaktorieren.

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

## Besserer Weg

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

## Warum es wichtig ist

Die meisten Teams, die Microservices zu früh einführen, werden langsamer, nicht schneller, weil sie den Overhead verteilter Systeme übernehmen, bevor sie ihn benötigen.

Wenn Sie Grenzen zunächst im Monolithen halten, können Sie die Domäne kostengünstig kennenlernen und später entlang der richtigen Nähte aufteilen.