Mikä on hajautettu monolittti ja muut mikropalveluiden anti-kuviot?

Question

Accepted Answer

Huonoin mikropalveluiden tulos on **"hajautettu monolittti"**: palvelut, jotka ovat fyysisesti erillään mutta niin tiiviisti kytketyt, että ne on otettava käyttöön yhdessä — saat kaikki jakelun kustannukset ilman riippumattomuutta.

## Hajautetun monolitin merkit

```text
✗ Changing one service forces redeploying several others
✗ Services share a database / shared schema
✗ A single request fans out through many synchronous hops
✗ Releases must be coordinated across teams
→ you pay network + ops cost but lost independent deployability
```

## Muut yleiset anti-kuviot

| Anti-kuvio | Ongelma |
|---|---|
| Jaettu tietokanta | Palveluiden uudelleenkytkeminen; ei riippumatonta skeeman muuttamista |
| Puhelias palvelut | Monta synkronista kutsua per pyyntö → viive, hauras |
| Nano-palvelut | Liian pieni rakeisto; yleiskustannukset peittävät logiikan |
| Ei API-versiointia | Yksi muutos rikkoo jokaisen kuluttajan |
| Synkroniset ketjut | Viive ja epäonnistuminen kertautuvat A→B→C→D:n kohdalla |
| Jumalapalvelu | Yksi palvelu, josta kaikki riippuvat (uusi monolitti) |

## Perimmäinen syy

Yleensä **väärät rajat**. Palvelut, jotka on jaettu teknisen kerroksen tai yksikön mukaan (ei liiketoimintakyky), päätyvät puheliaaksi ja keskinäisesti riippuvaisiksi.

```text
bad:  User-svc, Product-svc, Cart-svc all called for one checkout
good: Checkout owns the capability end to end
```

## Miksi sillä on merkitystä

Hajautettu monolitti on tiukasti huonompi kuin oikea monolitti — hitaampi, vaikeampi virheenkorjaukseen, enemmän käyttää, silti mahdoton ottaa käyttöön itsenäisesti.

Suurin osa anti-kuvioista juontaa juurensa rajoihin ja jaettuun tietokantaan, joten bounded contexts ja tiedon omistajuuden oikea määrittäminen on se, mikä erottaa mikropalvelut, jotka auttavat, niistä, jotka vahingoittavat.

Anti-kuvio	Ongelma
Jaettu tietokanta	Palveluiden uudelleenkytkeminen; ei riippumatonta skeeman muuttamista
Puhelias palvelut	Monta synkronista kutsua per pyyntö → viive, hauras
Nano-palvelut	Liian pieni rakeisto; yleiskustannukset peittävät logiikan
Ei API-versiointia	Yksi muutos rikkoo jokaisen kuluttajan
Synkroniset ketjut	Viive ja epäonnistuminen kertautuvat A→B→C→D:n kohdalla
Jumalapalvelu	Yksi palvelu, josta kaikki riippuvat (uusi monolitti)