Kdaj microservices NE smete uporabljati?

Question

Accepted Answer

Microservices so pogosto **napačna** začetna izbira. Splošno pravilo je **"monolith first"**: začnite z dobro strukturiranim monolitom in ekstrahirajte storitve samo, če imate konkreten razlog.

## Izogibajte se microservices, kadar

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

## Strošek prezgodnjega deljenja

Premikanje zaokrožitve (in-process method call) v mrežni klic dodaja zakasnitev, načine napak, serializacijo in enoto za razporeditev. Če so meje napačne, plačate vse to **in** še vedno morate refaktorirati med storitvami.

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

## Boljša pot

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

## Zakaj je to pomembno

Večina timov, ki prevzamejo microservices prezgodaj, postane počasnejša, ne hitrejša, ker prevzamejo obremenjenost porazdeljenih sistemov, preden jo potrebujejo.

Zadrževanje mej znotraj monolita najprej vam omogoči, da poceni spoznate domeno in jo pozneje razdelite po pravih šivih.