Mikor NEM szabad mikrozolgáltatásokat használni?

Question

Accepted Answer

A mikrozolgáltatások gyakran a **rossz** kezdeti választás. Szokásos szabály a **"monolitikus-első"** megközelítés: kezdjen egy jól strukturált monolittal, és csak akkor bontson ki szolgáltatásokat, ha konkrét oka van.

## Kerülje a mikrozolgáltatásokat, amikor

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

## Az idő előtti felosztás költsége

Egy in-process metódushívás hálózati hívássá való áthelyezése késleltetést, meghibásodási módokat, szérializálást és egy telepítési egységet adhat. Ha a határok rosszak, akkor mindezért fizetsz **és** még mindig át kell szervezned a szolgáltatások között.

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

## Jobb megközelítés

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

## Miért fontos ez

A legtöbb csapat, amely túl korán alkalmazza a mikrozolgáltatásokat, végül lassabbá válik, nem pedig gyorsabbá, mert az elosztott rendszerek terheit vállalják, mielőtt szükségük lenne rájuk.

A határok monolituson belüli megtartása lehetővé teszi, hogy olcsón tanuljon a tartományról, és később a megfelelő helyeken ossza fel.