Kiedy NIE powinieneś używać mikrousług?

Question

Accepted Answer

Mikrousługi są często **złym** wyborem na początek. Powszechną regułą jest **"najpierw monolitł"**: zacznij od dobrze ustrukturyzowanego monolitu i ekstrahuj usługi tylko wtedy, gdy masz konkretny powód.

## Unikaj mikrousług gdy

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

## Koszt przedwczesnego dzielenia

Przeniesienie wewnątrz-procesowego wywołania metody na wywołanie sieciowe dodaje opóźnienie, tryby awarii, serializację i jednostkę wdrażania. Jeśli granice są błędne, płacisz za wszystko to **i** nadal musisz refaktorować na wielu usługach.

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

## Lepszy путь

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

## Dlaczego to ważne

Większość zespołów, które zbyt wcześnie przyjmą mikrousługi, kończy się wolniej, nie szybciej, ponieważ biorą na siebie obciążenie systemów rozproszonych zanim go potrzebują.

Utrzymanie granic wewnątrz monolitu na początku pozwala ci tanio poznać domenę i później podzielić się wzdłuż odpowiednich linii podziału.