서비스는 동기적으로(REST나 gRPC를 통한 요청/응답) 또는 비동기적으로(Kafka나 RabbitMQ 같은 브로커를 통한 메시지/이벤트) 통신합니다.
동기(요청/응답)
호출자는 응답을 기다립니다. 단순하고 직관적이지만 가용성을 결합시킵니다. 즉, 피호출자가 다운되면 호출자도 영향을 받습니다.
http
GET /orders/42 HTTP/1.1
Host: orders-service
Accept: application/json
비동기(메시징/이벤트)
발신자는 메시지를 발행하고 다음 작업으로 넘어갑니다. 소비자는 나중에 그것을 처리합니다. 이는 서비스를 시간적으로 분리합니다.
text
Order Service ──"OrderPlaced" 발행──▶ [ Broker ] ──▶ Email Service
│
└──▶ Inventory Service
언제 무엇을 쓸까
| 필요 | 선택 |
|---|---|
| 사용자에게 즉각적인 응답 | 동기 |
함정
긴 동기 호출 체인(A → B → C → D)은 지연 시간과 장애 확률을 곱셈으로 증가시킵니다. 가능하면 비동기나 집계를 선호하세요.
왜 중요한가
통신 스타일은 시스템의 복원력을 결정합니다. 동기 호출은 추론하기 쉽지만 런타임에서 강한 결합을 만들고, 비동기 메시징은 eventual consistency를 대가로 분리를 얻습니다.
대부분의 실제 시스템은 두 가지를 혼합합니다. 사용자 대면 읽기에는 동기를, 백그라운드 워크플로에는 비동기를 사용합니다.
