Hvordan kommunikerer mikroservices med hinanden?

Question

Accepted Answer

Tjenester kommunikerer enten **synkront** (anmodning/svar via REST eller gRPC) eller **asynkront** (meddelelser/begivenheder gennem en broker som Kafka eller RabbitMQ).

## Synkront (anmodning/svar)

Kaldende venter på et svar. Enkelt og intuitivt, men det binder tilgængelighed — hvis kaldt er nede, påvirkes kalleren.

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

## Asynkront (messaging/begivenheder)

Afsendere udgiver en besked og fortsætter; forbrugere behandler den senere. Dette adskiller tjenester i tid.

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

## Hvornår skal man bruge hvad

| Behov | Vælg |
|---|---|
| Øjeblikkelig svar til brugeren | Synkront |
| Adskillelse, buffering, fan-out | Asynkront |
| Stærk tidskobling OK | Synkront |
| Modstandskraft over for downstream-afbrydelser | Asynkront |

## Faldgrube

Lange **synkrone kæder** (A → B → C → D) multiplicerer latency og fejlsandsynlighed. Foretrækk asynkront eller aggregering hvor muligt.

## Hvorfor det betyder noget

Kommunikationsstilen former systemets modstandskraft: synkrone opkald er nemme at ræsonnere om, men skaber tæt runtime-kobling, mens asynkron beskedveksling opnår afkobling til prisen for eventuel konsistens.

De fleste virkelige systemer blander begge dele — synkront for brugervendte læsninger, asynkront for baggrundsworkflows.

Behov	Vælg
Øjeblikkelig svar til brugeren	Synkront
Adskillelse, buffering, fan-out	Asynkront
Stærk tidskobling OK	Synkront
Modstandskraft over for downstream-afbrydelser	Asynkront