Kada NE trebate koristiti mikroservise?

Question

Accepted Answer

Mikroservise su često **pogrešan** početni izbor. Obično se kaže **"monolith prvo"**: počnite s dobro strukturiranim monolitom i ekstrahirajte servise samo kada imate konkretnog razloga.

## Izbjegavajte mikroservise kada

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

## Cijena preuranjene podjele

Premještanje in-process poziva metode na mrežni poziv dodaje kašnjenje, slučajeve kvarenja, serijalizaciju i jedinicu implementacije. Ako su granice krivo postavljene, plaćate sve to **i** ipak morate refaktorirati niz servise.

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

## Bolji pristup

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

## Zašto je to važno

Većina timova koji prerano usvoje mikroservise na kraju su sporiji, ne brži, jer preuzimu režijske troškove distribuiranih sustava prije nego što ih trebaju.

Zadržavanje granica unutar monolita prvo omogućuje vam da jeftinije naučite domenu i da je kasnije podijelite duž ispravnih linija.