Come comunicano i microservizi tra loro?

Question

Accepted Answer

I servizi comunicano sia **sincroni** (request/response tramite REST o gRPC) che **asincroni** (messaggi/eventi attraverso un broker come Kafka o RabbitMQ).

## Sincroni (request/response)

Chi chiama attende una risposta. Semplice e intuitivo, ma accoppia la disponibilità — se il servizio chiamato è giù, chi chiama è colpito.

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

## Asincroni (messaggi/eventi)

Chi invia pubblica un messaggio e va avanti; i consumer lo elaborano più tardi. Questo disaccoppia i servizi nel tempo.

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

## Quando usare quale

| Necessità | Scegli |
|---|---|
| Risposta immediata per l'utente | Sincrono |
| Disaccoppiamento, buffering, fan-out | Asincrono |
| Forte accoppiamento temporale OK | Sincrono |
| Resilienza a guasti downstream | Asincrono |

## Trappola

Lunghe **catene sincrone** (A → B → C → D) moltiplicano latenza e probabilità di guasto. Preferisci async o aggregazione dove possibile.

## Perché è importante

Lo stile di comunicazione forma la resilienza del sistema: le chiamate sincrone sono facili da ragionare ma creano un accoppiamento runtime stretto, mentre la messagistica asincrona compra disaccoppiamento al costo della consistenza eventuale.

La maggior parte dei sistemi reali mischiano entrambi — sincrono per letture rivolte all'utente, asincrono per workflow in background.

Necessità	Scegli
Risposta immediata per l'utente	Sincrono
Disaccoppiamento, buffering, fan-out	Asincrono
Forte accoppiamento temporale OK	Sincrono
Resilienza a guasti downstream	Asincrono