Când NU ar trebui să folosești microservicii?

Question

Accepted Answer

Microserviciile sunt adesea **alegerea greșită** pentru a incepe. O regulă comună este **"monolitl întâi"**: începe cu un monolith bine structurat și extrage servicii doar când ai un motiv concret.

## Evită microserviciile când

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

## Costul divizării premature

Mutarea unui apel de metodă în proces la un apel de rețea adaugă latență, moduri de defecțiune, serializare și o unitate de implementare. Dacă limitele sunt greșite, plătești toate acestea **și** trebuie să refactorezi pe servicii.

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

## Cale mai bună

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

## De ce este important

Majoritatea echipelor care adoptă microserviciile prea devreme ajung mai lente, nu mai rapide, deoarece preiau supraîncărcarea sistemelor distribuite înainte de a fi avute nevoie.

Păstrarea limitelor în interiorul unui monolith mai întâi te lasă să înveți domeniul ieftin și să te împarți de-a lungul cusăturilor potrivite mai târziu.