Wie kommunizieren Microservices miteinander?

Question

Accepted Answer

Services kommunizieren entweder **synchron** (Request/Response über REST oder gRPC) oder **asynchron** (Nachrichten/Events über einen Broker wie Kafka oder RabbitMQ).

## Synchron (Request/Response)

Der Aufrufer wartet auf eine Antwort. Einfach und intuitiv, aber es bindet die Verfügbarkeit — wenn der Aufgerufene ausfällt, ist der Aufrufer betroffen.

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

## Asynchron (Messaging/Events)

Der Sender veröffentlicht eine Nachricht und macht weiter; Consumer verarbeiten diese später. Dies entkoppelt Services zeitlich.

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

## Wann welche Methode verwenden

| Anforderung | Wählen Sie |
|---|---|
| Sofortige Antwort für den Benutzer | Synchron |
| Entkopplung, Pufferung, Fan-out | Asynchron |
| Starke zeitliche Kopplung OK | Synchron |
| Resilienz gegen Ausfälle nachgelagerter Services | Asynchron |

## Fallstricke

Lange **synchrone Ketten** (A → B → C → D) vervielfachen Latenz und Ausfallwahrscheinlichkeit. Bevorzugen Sie asynchron oder Aggregation, wo möglich.

## Warum es wichtig ist

Der Kommunikationsstil prägt die Resilienz des Systems: Synchrone Aufrufe sind leicht zu verstehen, schaffen aber enge Runtime-Kopplungen, während asynchrones Messaging Entkopplung auf Kosten von Eventually Consistency erreicht.

Die meisten realen Systeme mischen beide — synchron für benutzerfreundliche Lesevorgänge, asynchron für Hintergrund-Workflows.

Anforderung	Wählen Sie
Sofortige Antwort für den Benutzer	Synchron
Entkopplung, Pufferung, Fan-out	Asynchron
Starke zeitliche Kopplung OK	Synchron
Resilienz gegen Ausfälle nachgelagerter Services	Asynchron