Hur kommunicerar mikrotjänster med varandra?

Question

Accepted Answer

Tjänster kommunicerar antingen **synkront** (begäran/svar över REST eller gRPC) eller **asynkront** (meddelanden/händelser via en mäklare som Kafka eller RabbitMQ).

## Synkront (begäran/svar)

Anroparen väntar på ett svar. Enkelt och intuitivt, men det kopplar tillgänglighet — om den anropade tjänsten är nere, påverkas anroparen.

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

## Asynkront (meddelanden/händelser)

Avsändaren publicerar ett meddelande och fortsätter; konsumenter bearbetar det senare. Detta frikopplar tjänster i tid.

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

## När man ska använda vilken

| Behov | Välj |
|---|---|
| Omedelbar svar till användaren | Synkront |
| Frikoppling, buffring, spridning | Asynkront |
| Stark temporal koppling OK | Synkront |
| Motståndskraft mot driftproblem | Asynkront |

## Fallgrop

Långa **synkrona kedjor** (A → B → C → D) multiplicerar latens och felfrekvens. Föredra asynkront eller aggregering där möjligt.

## Varför det är viktigt

Kommunikationssilen formar systemets motståndskraft: synkrona anrop är lätta att resonera om men skapar tätt koppling under körning, medan asynkrona meddelanden erbjuder frikoppling till kostnaden för slutlig konsistens.

De flesta verkliga system blandar båda — synkront för användarorienterad läsning, asynkront för bakgrundsarbetsflöden.

Behov	Välj
Omedelbar svar till användaren	Synkront
Frikoppling, buffring, spridning	Asynkront
Stark temporal koppling OK	Synkront
Motståndskraft mot driftproblem	Asynkront