Introduction
The Publish/Subscribe pattern, often shortened to Pub/Sub, allows parts of a software system to communicate with each other.
The Basics of Pub/Sub
Imagine you have an app that needs to send updates to users. With Pub/Sub, you have a system that's split into four main parts:
Publisher: This is the part that sends out messages. Think of it as the app sending updates.
Subscriber: This is the part that receives messages. It's like the app on your phone that gets the update.
Topic: This is a way to organize messages. For example, one topic could be for app updates, and another could be for new messages.
Message: This is the actual information being sent from the publisher to the subscriber.
Why Use Pub/Sub?
The Pub/Sub model lets publishers send messages without waiting, so subscribers can get them when they can.
This asynchronous approach means senders don't have to stop and wait.
Adding more subscribers is easy without needing to change anything for the publishers, making everything work smoothly and quickly.
How Messages Get Delivered
Pub/Sub systems can deliver messages in different ways:
At most once: The message is sent once but might not get delivered.
At least once: The message definitely gets delivered, but it might arrive more than once.
Exactly once: The message is guaranteed to be delivered once and only once.
Making Sure Messages Don't Cause Problems
When a message is sent more than once, it's important that it doesn't mess anything up. This is where idempotency comes in. An idempotent message can be received multiple times without causing any issues. No matter how often the message is received, it will yield the same result.
Keeping Messages in Order
In Pub/Sub systems, messages are not guaranteed to arrive in the order they were sent. For instance, Google Cloud Pub/Sub supports ordered delivery by using ordering keys, which group messages into sequences that are delivered in order. This makes sure messages that are grouped together get delivered in the right order.
But, ensuring messages stay in order means you might have to deal with slower message handling and more complex setups, especially if a message doesn't get through correctly. For example, if one message gets stuck, others with the same key might also get held up, slowing things down.
Why Different Topics?
Using different topics lets you organize messages based on their type. For instance, one topic might be for notifications, while another for user messages. This helps in making sure the right messages get to the right subscribers.
Many tools exist for setting up a Pub/Sub system.
Some of the well-known ones include:
Amazon SNS
Azure Web PubSub
Google Cloud Pub/Sub
Wrapping Up
The Pub/Sub pattern is a smart way to make parts of your software talk to each other without getting too complicated.
It's like having a postal system that knows exactly where to deliver messages without the sender and receiver ever needing to meet.
Further reading
A Dead Letter Queue is an important component in Pub/Sub or Queue-based messaging system. You can read more about it here.
