När bör du INTE använda microservices?

Question

Accepted Answer

Microservices är ofta **fel** första val. En vanlig regel är **"monolith first"**: börja med en välstrukturerad monolith och extrahera tjänster endast när du har en konkret anledning.

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

## Kostnaden för förtidigt uppdelning

Att flytta ett in-process-metodanrop till ett nätverksanrop lägger till latens, fellägen, serialisering och en distributionsenhet. Om gränserna är fel betalar du allt det **och** måste fortfarande omstrukturera över tjänster.

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

## Bättre väg

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

## Varför det spelar roll

De flesta team som antar microservices för tidigt slutar långsammare, inte snabbare, eftersom de tar på sig distribuerade systemarkiv innan de behöver det.

Att behålla gränser inne i en monolith först låter dig lära dig domänen billigt och dela längs rätt söm senare.