Use Cases

Choose SNS if

• able to publish and consume batches of messages.
• allow some messages to be processed in multiple ways.
• Multiple subscribers are needed.

Choose SQS if

• no particular additional requirements.
• Decoupling to app and parallel asynchronous processing
• only one subscribers are needed.

SNS

Push 방식이라 100% 메시지가 전달됨을 보장하지 않는다.
글로벌 기업 애플조차도 10년전 99.97% 전달 보장.
모든 push 방식 Architecture 의 고질적 문제.

SQS

Polling 방식.

Short Polling

• When the call to ReceiveMessage must return immediately.
• When poll multiple queues in a single thread.

통상 1회 polling 에 수십~수백 milliseconds 만 소요된다. SQS 가 매우 잘 분산되어 있기 때문에 빠른 응답속도를 기대할 수 있다.

Long Polling (Recommended)

Often more preferable to short polling.

SQS는 고가용성을 보장하기 위해 내부적으로 여러 Queue로 구성되어있다. (큐를 하나 생성해도 실제로는 하나가 아니다)
Consumer 가 메시지를 가져갈 때 가시성 제한을 걸게되어있다.
모든 상태를 큐간 동기화하는 메커니즘이 존재한다.
아키텍쳐 설계상 Standard Queue 는 한 번만 보장되지 않는다.
FIFO Queue 는 메시지당 Locking 이 걸려있는 것으로 추정된다. (무적권 1회 처리 보장)

Standard Queue

Decision Tree

---

Refeferece

• SQS FAQ - AWS Document
• Difference between SQS and SNS - medium
• AWS SQS Long Polling vs Short Polling - pragmaticnotes
• Event-Driven Architectures with SNS, SQS & Lambda