기존 Request-Response 구조의 장단점

 장점

• 사용이 용이함
• Stateless (HTTP)

단점

• Reciever가 여러개 있는 경우 스케일이 용이하지 않음
• 여러 서비스간 커플링이 발생
• 요청을 처리하기 위해 클라이언트와 서버가 동시에 작동하는 상태여야 함
• 문제들을 해결하기 위해 chaining, retries, circuit breaker등을 사용

Publish-Subscribe 모델

Message Queue/Topic이 middleware layer형식으로 존재

Publihser는 message queue/topic에 message를  post함

Subscriber는 새로운 메시지가 있는 경우 알림을 받고 정해진 일을 수행

Redis, kafka, RabbitMQ 등

장점

• 여러 receiver가 있어도 확장이 용이
• 디커플링
• 캐싱
• Publisher나 Subscriber가 작동하지 않아도 동작
• Microservice에 좋음
•  event-driven구조와 어울림

단점

• 메시지 전송 이슈 (정확하게 하나의 메시지가 한번만 전송을 보장해야함, Two General's Problem)
• Network Saturation (push모델의 경우 너무 많은 메시지를 푸슁, pull 모델의 경우 false attempts
• 그래도 확장이 문제

Two General's Problem

-  메시지를 받았는데 메시지를 받아서 처리했는지 확인할 방법이 없음 -> 같은 오더를 여러번 전송하게 됨 -> 같은 오더가 여러번 처리됨

- 해결방안 : idempotency token -> 서버는 idempotency token을 가지고 있다가 같은 token을 가진 요청이 다시 들어오면 먼저 요청의 카피를 계속 전송함 -> 같은 요청이 반복적으롣 들어와도 한번만 실행됨