Kdy byste NEMĚLI používat mikroslužby?

Question

Accepted Answer

Mikroslužby jsou často **špatná** výchozí volba. Běžné pravidlo je **"monolitní přístup nejprve"**: začněte s dobře strukturovaným monolitem a extrahujte služby pouze tehdy, máte-li konkrétní důvod.

## Vyhněte se mikroslužbám, když

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

## Cena předčasného rozdělení

Přesunutí volání in-process metody na síťové volání přidává latenci, režimy selhání, serializaci a jednotku nasazení. Pokud jsou hranice nesprávné, platíte vše to **a** stále musíte refaktorovat napříč službami.

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

## Lepší cesta

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

## Proč je to důležité

Většina týmů, které příliš brzy zavedou mikroslužby, skončí pomalejší, ne rychlejší, protože si vezou režii distribuovaných systémů dříve, než ji potřebují.

Zachování hranic uvnitř monolitu nejprve vám umožňuje levně se naučit doménu a později se rozdělit podél správných švů.