Cum comunică microservicelele între ele?

Question

Accepted Answer

Serviciile comunică fie **sincron** (cerere/răspuns peste REST sau gRPC), fie **asincron** (mesaje/evenimente printr-un broker ca Kafka sau RabbitMQ).

## Sincron (cerere/răspuns)

Apelantul așteaptă un răspuns. Simplu și intuitiv, dar leagă disponibilitatea — dacă apelatul este inactiv, apelantul este afectat.

```http
GET /orders/42 HTTP/1.1
Host: orders-service
Accept: application/json
```

## Asincron (mesaje/evenimente)

Trimitorul publică un mesaj și continuă; consumatorii îl procesează mai târziu. Aceasta decuplează serviciile în timp.

```text
Order Service ──publish "OrderPlaced"──▶ [ Broker ] ──▶ Email Service
                                              │
                                              └──▶ Inventory Service
```

## Când să folosești care

| Nevoie | Alege |
|---|---|
| Răspuns imediat pentru utilizator | Sincron |
| Decuplare, buffering, fan-out | Asincron |
| Cuplare temporală puternică OK | Sincron |
| Reziliență la defecțiuni în aval | Asincron |

## Capcană

Lanțuri **sincrone** lungi (A → B → C → D) multiplică latența și probabilitatea de defecțiune. Preferă async sau agregare unde este posibil.

## De ce contează

Stilul de comunicare dă formă rezistenței sistemului: apelurile sincrone sunt ușor de analizat, dar creează o cuplare puternică la runtime, în timp ce mesajele asincrone cumpără decuplare cu preț de consistență finală.

Majoritatea sistemelor reale amestecă ambele — sync pentru citiri orientate către utilizator, async pentru fluxuri de lucru în fundal.

Nevoie	Alege
Răspuns imediat pentru utilizator	Sincron
Decuplare, buffering, fan-out	Asincron
Cuplare temporală puternică OK	Sincron
Reziliență la defecțiuni în aval	Asincron