Hvornår bør du IKKE bruge microservices?

Question

Accepted Answer

Microservices er ofte det **forkerte** startvalg. En almindelig regel er **"monolith først"**: start med en velstruktureret monolith og udskil tjenester kun når du har en konkret grund.

## Undgå microservices når

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

## Omkostningen ved for tidlig opdeling

At flytte et in-process metodekald til et netværkskald tilføjer latency, fejltilstande, serialisering og en deploymentsenhed. Hvis grænserne er forkerte, betaler du alt det **og** skal stadig refaktorere på tværs af tjenester.

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

## Bedre vej

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

## Hvorfor det betyder noget

De fleste hold, der vedtager microservices for tidligt, ender langsommere, ikke hurtigere, fordi de påtager sig distributed-systems overhead før de har brug for det.

At holde grænserne inde i en monolith først lader dig lære domænet billigt og senere dele langs de rigtige søm.