Når skal du IKKE bruke microservices?

Question

Accepted Answer

Microservices er ofte det **feil** startvalget. En vanlig regel er **"monolith først"**: start med en velstrukturert monolitt og ekstrakt services bare når du har en konkret grunn.

## Unngå 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
```

## Kostnadene ved for tidlig oppdeling

Å flytte et in-process metodekall til et nettverkskall legger til latens, feilmodi, serialisering og en distribusjonssenhet. Hvis grensene er feil, betaler du alt det **og** må fortsatt refaktorere på tvers av tjenester.

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

## Bedre vei

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

De fleste team som tar i bruk microservices for tidlig ender opp langsommere, ikke raskere, fordi de tar på seg distribuert-systemkostnader før de trenger det.

Å holde grenser inne i en monolitt først lar deg lære domenet billig og dele langs de riktige sømene senere.