Skip to main content

Command Palette

Search for a command to run...

The Push and Pull: A Simple Guide to SNS (Publish or Subscribe) and SQS (Queueing)

Updated
4 min read
The Push and Pull: A Simple Guide to SNS (Publish or Subscribe) and SQS (Queueing)

The Push and Pull: A Simple Guide to SNS (Publish/Subscribe) and SQS (Queueing)

So you've heard whispers of SNS and SQS in the AWS cloud, and maybe you're feeling a bit lost in the jargon. Don't worry, we're here to demystify these powerful services. Think of them as different ways to handle messages between different parts of your application, and you're already halfway there!

This guide will break down SNS (Simple Notification Service) and SQS (Simple Queue Service) using simple language, relatable analogies, and a real-world example. Let's dive in!

What are SNS and SQS?

Essentially, SNS and SQS are messaging services. They allow different components of your application (often called services or microservices) to communicate with each other without being directly dependent. This is a key principle for building scalable and resilient applications in the cloud.

  • SNS (Simple Notification Service): The Public Announcement System (PUSH)

    Think of SNS as a public announcement system. Imagine a community bulletin board. Anyone can post a message to the board (the "topic"). Then, anyone who has subscribed to the board (the "subscribers") will automatically receive a copy of every message posted. SNS pushes messages to its subscribers.

  • SQS (Simple Queue Service): The Task Queue (PULL)

    Now imagine a to-do list taped to your refrigerator. Tasks are added to the list (the "queue"). Individuals (the "consumers") then come along, grab a task from the list, complete it, and mark it as done. SQS holds messages in a queue, and consumers actively pull messages from the queue.

SNS (Publish/Subscribe) in Detail

  • Publisher: The application component sending the message.

  • Topic: A logical access point and communication channel. Publishers send messages to topics.

  • Subscriber: The application component receiving the message. Subscribers can be subscribed to a topic in various ways, such as:

    • Email: Receive notifications in your inbox.

    • SMS: Get text messages.

    • HTTP/HTTPS: Trigger webhooks or API calls.

    • SQS: Send messages to an SQS queue (more on this later!).

    • AWS Lambda: Trigger a Lambda function.

SQS (Queueing) in Detail

  • Producer: The application component sending the message to the queue.

  • Queue: A temporary storage space for messages.

  • Consumer: The application component that retrieves messages from the queue and processes them.

A Real-World Example: E-Commerce Order Processing

Let's imagine an e-commerce website. When a customer places an order, several things need to happen:

  1. Send an email confirmation to the customer.

  2. Update the inventory database.

  3. Initiate the shipping process.

  4. Send a notification to the finance team for billing.

Using SNS and SQS, we can make this process more reliable and scalable:

  • SNS: The order processing service publishes a message to an SNS topic called "OrderPlaced".

    • The email service is subscribed to this topic and immediately sends the order confirmation email.

    • The finance team has configured a subscription to receive notifications of new orders via email for reporting.

  • SQS: The order processing service also puts a message into an SQS queue called "InventoryUpdates".

    • An inventory update service pulls messages from this queue, updating the database.

    • Similarly, another SQS queue called "ShippingRequests" receives messages for the shipping service to process.

Architectural Diagram:

  +---------------------+      +---------------------+
  | Order Processing    |------>| SNS Topic:          |
  | Service             |      | OrderPlaced         |
  +---------------------+      +---------------------+
         |                      /        |        \
         |                     /         |         \
         |      +-------------+  +-------------+  +-------------+
         |      | Email Service |  | Finance Team|  |  SQS Queue:  |
         |      | (Email)       |  | (Email)      |  |InventoryUpdates|
         |      +-------------+  +-------------+  +-------------+
         |                                           |
         |      +-----------------------+            |
         +------>| SQS Queue:            |<-----------+
                | ShippingRequests      |
                +-----------------------+

Benefits of using SNS and SQS in this scenario:

  • Decoupling: The order processing service doesn't need to know the details of how the email service, inventory service, shipping service, or finance team work.

  • Scalability: Each service can scale independently based on its own workload. The inventory service can scale separately from the email service.

  • Resilience: If the inventory service is temporarily unavailable, the messages will simply remain in the SQS queue until it comes back online. The email service will function unaffected.

  • Flexibility: Adding a new service (e.g., a loyalty points system) is as simple as subscribing it to the appropriate SNS topic or creating a new SQS queue.

A Challenge and Solution: Message Ordering in SQS

One common challenge with SQS is that messages are not guaranteed to be delivered in the exact order they were sent, especially in a distributed system. This can be a problem if the order of events matters.

Solution: Use FIFO (First-In, First-Out) Queues in SQS. FIFO queues preserve the order of messages and deliver them exactly once. However, FIFO queues have limitations in terms of throughput compared to standard queues.

Key Takeaways:

  • SNS is a push mechanism used for broadcasting messages to multiple subscribers. Think of it as a public announcement system.

  • SQS is a pull mechanism used for queuing messages for processing by consumers. Think of it as a to-do list.

  • Using SNS and SQS together promotes decoupling, scalability, and resilience in your applications.

  • Choose the right type of SQS queue (Standard or FIFO) based on your message ordering requirements.

By understanding these simple analogies and practical examples, you can begin to leverage the power of SNS and SQS to build robust and scalable applications in the cloud. Happy messaging!