Hoe communiceren microservices met elkaar?

Question

Accepted Answer

Services communiceren ofwel **synchroon** (aanvraag/antwoord over REST of gRPC) ofwel **asynchroon** (berichten/events via een broker zoals Kafka of RabbitMQ).

## Synchrone (aanvraag/antwoord)

De aanvrager wacht op een antwoord. Eenvoudig en intuïtief, maar het koppelt beschikbaarheid — als de aangeroepene niet beschikbaar is, wordt de aanvrager getroffen.

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

## Asynchrone (berichten/events)

De afzender publiceert een bericht en gaat verder; consumenten verwerken het later. Dit ontkoppelt services in de tijd.

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

## Wanneer welke gebruiken

| Behoefte | Kies |
|---|---|
| Direct antwoord voor de gebruiker | Synchroon |
| Ontkoppeling, buffering, fan-out | Asynchroon |
| Sterke temporele koppeling OK | Synchroon |
| Veerkracht tegen downtime downstream | Asynchroon |

## Valkuil

Lange **synchrone ketens** (A → B → C → D) vermenigvuldigen latentie en faalwaarde. Geef de voorkeur aan async of aggregatie waar mogelijk.

## Waarom het belangrijk is

De communicatiestijl bepaalt de veerkracht van het systeem: synchrone calls zijn gemakkelijk te begrijpen maar creëren strikte runtime-koppeling, terwijl async messaging ontkoppeling koopt tegen de prijs van uiteindelijke consistentie.

De meeste echte systemen mengen beide — sync voor gebruikersgerichte leesbewerkingen, async voor achtergrondworkflows.

Behoefte	Kies
Direct antwoord voor de gebruiker	Synchroon
Ontkoppeling, buffering, fan-out	Asynchroon
Sterke temporele koppeling OK	Synchroon
Veerkracht tegen downtime downstream	Asynchroon