Kada jūs NETURĖTUMĖTE naudoti mikrotarnybas?

Question

Accepted Answer

Mikrotarnybos dažnai yra **netinkamas** pradinis pasirinkimas. Bendra taisyklė yra **"monolit pirmiausia"**: pradėkite nuo gerai struktūrizuoto monolito ir išskirkite paslaugas tik tada, kai turite konkretų pagrindą.

## Vengkite mikrotarnybų kai

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

## Ankstyvesnio skaidymo kaina

Iš vidaus proceso metodo skambučio perkėlimas į tinklo skambutį prideda latenciją, gedimų režimus, serializavimą ir diegimo vienetą. Jei ribos nėra tinkamos, jūs mokate visus šiuos kaštus **ir** vis tiek turite perrašyti kodą visose paslaugose.

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

## Geresnė kelyje

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

## Kodėl tai svarbu

Dauguma komandų, kurios per anksti pradeda naudoti mikrotarnybas, baigia dirbti lėčiau, o ne greičiau, nes jie perimą paskirstytų sistemų apkrovą prieš jo reikalaudami.

Išlaikiusi ribas monolyto viduje pradžioje galite pigiai pažinti domeną ir vėliau padalinti pagal tinkamas siūles.