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.
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.
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.