Shërbimet komunikojnë ose në mënyrë sinkrone (kërkesë/përgjigje përmes REST ose gRPC) ose në mënyrë asinkrone (mesazhe/ngjarje përmes një broker si Kafka ose RabbitMQ).
Përdoruesi që bën thirrjen pret për një përgjigje. Është e thjeshtë dhe intuitive, por krijon lidhje të disponueshmërisë — nëse shërbimi i thirrur është zbritur, përdoruesi që bën thirrjen preket.
GET /orders/42 HTTP/1.1
Host: orders-service
Accept: application/json
Dërguesit publikon një mesazh dhe kalon më tutje; konsumatorët e përpunojnë atë më vonë. Kjo e ndanë shërbimet në kohë.
Order Service ──publish "OrderPlaced"──▶ [ Broker ] ──▶ Email Service
│
└──▶ Inventory Service
| Kërkesë | Zgjidheni |
|---|---|
| Përgjigje e menjëhershme për përdoruesin | Sinkron |
| Ndarja, memorja buferike, përhapur | Asinkron |
| Bashkimi kohor i fortë OK | Sinkron |
| Rezilencë ndaj dështimit të shërbimeve të poshtëm | Asinkron |
Zinxhirë sinkronë të gjatë (A → B → C → D) shumëzojnë vonesën dhe probabilitetin e dështimit. Preferoni asinkron ose grumbullim kur është e mundur.
Stili i komunikimit formon reziliencën e sistemit: thirrjet sinkrone janë të lehta për t'u arsyetuar, por krijojnë bashkimin e ngushtë në kohën e ekzekutimit, ndërsa mesazhet asinkrone fitojnë ndarja me koston e konsistencës përfundimtare.
Shumica e sistemeve reale kombinojnë të dyja — sinkron për lexime me përqendrim të përdoruesit, asinkron për rrjedhat e punës në sfond.