Day 1에서 본 SQS는 "두 컴포넌트를 시간적으로 떼어내되 메시지는 한 번 소비되고 사라진다"는 큐 모델이었다. 그런데 실제 시스템에서는 "주문이 들어왔다"는 한 사건을 결제·재고·배송·메일·검색 인덱스·데이터 웨어하우스 여섯 군데가 각자 독립적으로 알아야 하는 경우가 훨씬 흔하다. 큐는 한 메시지를 한 컨슈머가 가져가면 다른 컨슈머는 못 보므로, 이 시나리오를 큐로 풀려면 큐를 여섯 개 만들고 생산자가 여섯 번 send 해야 한다. 새 컨슈머가 추가될 때마다 생산자 코드를 고쳐야 하고, 이건 1968년 Edsger Dijkstra가 지적한 "tightly coupled module"의 정의 그 자체다.
Publish/Subscribe(Pub/Sub) 패턴은 이 문제에 대한 1987년 ISIS 시스템 시절부터의 답이다. 생산자는 "토픽"에 한 번만 발행하고, 누가 그걸 구독하는지는 모른다. 구독자는 자유롭게 추가·제거되며, 토픽이 둘 사이의 indirection 레이어다. AWS의 **SNS(Simple Notification Service)**는 2010년 4월 출시된 이 모델의 매니지드 구현이고, 2006년 출시된 SQS와 짝을 이뤄 거의 모든 AWS 이벤트 기반 아키텍처의 척추 역할을 한다. 이 글은 SNS가 왜 그렇게 설계됐고, 어떤 트레이드오프를 SQS와 분담했으며, 시험과 운영에서 무엇이 함정인지 본다.
SNS의 모델은 단순하다