Hvordan kommuniserer mikrotjenester med hverandre?

Question

IT Interview Practice · Accepted Answer

Tjenester kommuniserer enten **synkront** (forespørsel/svar over REST eller gRPC) eller **asynkront** (meldinger/hendelser gjennom en megler som Kafka eller RabbitMQ).

## Synkront (forespørsel/svar)

Antroperen venter på et svar. Enkelt og intuitivt, men det kobler tilgjengelighet — hvis den som blir kalt er nede, påvirkes antroperen.

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

## Asynkront (meldinger/hendelser)

Avsenderen publiserer en melding og går videre; forbrukere behandler den senere. Dette frikobbler tjenester i tid.

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

## Når skal du bruke hvilken

| Behov | Velg |
|---|---|
| Umiddelbar svar for brukeren | Synkront |
| Frikobling, buffering, fan-out | Asynkront |
| Sterk tidsmessig kobling OK | Synkront |
| Motstandskraft mot nedtid nedstrøms | Asynkront |

## Fallgruver

Lange **synkrone kjeder** (A → B → C → D) multipliserer latens og sannsynlighet for feil. Foretrekk async eller aggregering der det er mulig.

## Hvorfor det er viktig

Kommunikasjonsstilen utformer systemets motstandskraft: synkrone oppkall er lette å resonnere om, men skaper tett kjøretidskobbling, mens async-meldinger kjøper frikobling til prisen av eventuell konsistens.

De fleste virkelige systemer blander begge deler — sync for brukervendt lesing, async for bakgrunnsarbeidsflyter.

Behov	Velg
Umiddelbar svar for brukeren	Synkront
Frikobling, buffering, fan-out	Asynkront
Sterk tidsmessig kobling OK	Synkront
Motstandskraft mot nedtid nedstrøms	Asynkront

Synkront (forespørsel/svar)

Asynkront (meldinger/hendelser)

Når skal du bruke hvilken

Fallgruver

Hvorfor det er viktig

Relaterte spørsmål