As a Cloud Architect, when should we use SNS and SQS?

Use Cases

SNS if:

• You need to publish and consume batches of messages.
• You want the same message to be processed in multiple ways.
• Multiple subscribers are needed, with fan-out messages to many subscribers.
• You require alerting and monitoring for application logs, infrastructure, etc.

SQS if:

• You need a simple queue with no additional requirements.
• You aim to decouple distributed systems and enable parallel asynchronous processing.
• Only one subscriber is needed.
• Your messages must be received sequentially and without loss, even in the event of system failures or network disruptions.

Combining SNS and SQS:

A fan-out pattern can be designed using both SNS and SQS. In this pattern, a message published to an SNS topic is distributed to multiple SQS queues in parallel.

• SQS: Primarily used to decouple applications.
• SNS: Distributes multiple copies of a message to several subscribers.

Differences: SQS Vs SNS

Entity Type:

• SQS: Queue (similar to JMS, MSMQ)
• SNS: Topic-Subscriber (Pub/Sub system)

Message Consumption:

• SQS: Pull Mechanism — Consumers poll messages from SQS.
• SNS: Push Mechanism — SNS pushes messages to consumers.

Persistence:

• SQS: Messages are persisted for a duration if no consumer is available. The retention period ranges from 1 minute to 14 days, with a default of 4 days.
• SNS: No persistence. Messages are delivered to available consumers at the time of arrival and then deleted. If no consumers are available, the message is lost.

Message Delivery Guarantee:

• SQS: Message delivery is guaranteed.
• SNS: Message delivery is not guaranteed.

Consumer Type:

• SQS: All consumers are expected to be identical and process messages in the same way.
• SNS: Consumers are expected to process messages in different ways