The Publish/Subscribe paradigm is a popular method of real-time messaging. Using the Pub/Sub pattern, publishers (sources of data) push messages out to any number of subscribers (receivers of data) that have subscribed to their topics. Different pub/sub topics are transmitted via live-feed data streams known as channels.
Pub/Sub is great for streaming, broadcasting, signaling devices, and many other on-demand uses. The inherent decoupling of publishers from their subscribers allows for easy scalability and real-time functionality. Messages can be sent independently and asynchronously to unlimited subscribers with very low latency.
In the worlds of software design and architecture, “Publish/Subscribe'' is a well-documented term. The Pub/Sub pattern is so important to real-time technology, we even named our company after a play on the phrase!
In this guide, we will cover how the Publish/Subscribe paradigm works, advantages and disadvantages to using the method in an application, and how PubNub implements Pub/Sub in our own real-time technology.
There are a few key definitions to understand when learning about the Publish/Subscribe method:
Publisher: Also known as a producer, a publisher is any component that creates messages and sends (publishes) them to a messaging service on a specified topic.
Subscriber: Also known as a consumer, a subscriber is any component that receives messages on a specified topic.
Message: A message is data that is published, or transported, through the messaging service. A message includes a header (metadata) and a payload, the intended information.
Topic: A topic is a specific category of information that is sent in publish/subscribe messaging.
Channel: Information on specific topics is sent through data streams called channels. A topic has an active channel if there is at least one subscriber.
In Pub/Sub messaging, publishers—the party that sends data—push messages to any number of interested subscribers. Devices can subscribe to multiple different channels, and they only receive message delivery from the topics they have subscribed to. These messages are asynchronous and completely separate from each other. Decoupling the data producer and its consumers allows for high-volume messaging and easy scalability.
Pub/Sub publishers are unique because they have no knowledge of, or relation to, their subscribers. This is different from something like a client-server connection, where the data is sent directly and requires their connection. Instead, Pub/Sub publishers sort information into channel streams, and publish directly to these live feeds depending on the topic.
Publishers are also capable of being subscribers to other channels, and data streams can be multiplexed. Channels can flow one-to-one (direct), from one publisher to many subscribers, or from many publishers to a single subscriber. This intercommunication allows for equal distribution of workloads and consistency, which is part of why this messaging system is so reliable.
It is common for Pub/Sub subscribers to use a managed service, known as a message broker system, to manage their channel subscriptions. Message brokers ensure that data is organized and delivered to the correct subscribers. For example, the popular ISO protocol Message Queue Telemetry Transport (MQTT) runs off of the Pub/Sub pattern. There are many open source brokers that assist with implementing this protocol in an application.
The Pub/Sub format also ensures that data is sent to subscribers in the exact order it is input and received by the publisher. This is great for real-time use cases where every second matters, for example, an app that tracks stock trading or a live scoreboard in an online game.
Pub/Sub messaging is usually part of a backend communication infrastructure, and is included within a larger message-oriented middleware system, like Java’s JMS. Another common paradigm included in middleware systems is the message queue.
Message queues also send data asynchronously, but instead of transmitting live feeds, their data is stored until the receiving party chooses to access it. Messages in a queue are intended for only one receiver, and data in the queue will usually be wiped after it is read by the targeted receiver. Pub/Sub data payloads go out to all of their subscribers before deleting.
Backend APIs will usually include both Pub/Sub and message queue models as part of their framework. They serve different needs and use cases. Pub/Sub services are more scalable and optimize lower latency, but Pub/Sub channels are less flexible than message queues.
One of Pub/Sub’s greatest advantages is that it allows systems to scale dynamically. Pub/Sub decouples publishers from their subscribers, which allows them to work independently. You can then develop and scale each component as needed without worrying about ripple effects in other areas.
Most importantly, this independence means that it is possible to direct scale as needed, without overloading any program components. By distributing resources, Pub/Sub messaging is able to scale Internet-wide and with global reach.
Pub/Sub messaging is programmed so that each component can minimize shared information. In the Publish/Subscribe method, communication is event-based and uses notifications. There is no need to poll servers for information, which decreases the latency.
Since the publishers and subscribers are decoupled, there are no service dependencies required for the data to transport and deliver. For example, in traditional coupling like a client-server relationship, a client requires the server to be running to send a message to the server. With Pub/Sub, separate publishers and subscribers are not concerned with the state of the other systems, which increases delivery consistency.
Pub/Sub is useful for managing workflows. For example, it is extremely efficient at moving data between databases and in storage. A large queue of tasks can be easily distributed among multiple devices for the most balanced workload.
Pub/Sub simplifies communication and allows devices to push notifications in real time. This allows instant delivery of critical updates and alerts, both on the backend and to any front-facing clients.
The Pub/Sub pattern is often used within automation, networking operations, and data centers, among many other industries that need real-time computing. Pub/Sub messaging is very useful for serverless computing and distributed cloud-based systems, like the Google cloud platform (GCP) or Amazon Web Services (AWS).
IoT is a very common use case for pub/sub messaging. Think of all the smart devices you may use on a daily basis - your phone, car, watch, maybe even your home appliances- these are all IoT endpoints. IoT technology can publish messages and push notifications to an unlimited number of these connected devices in real time. IoT updates are a great example of the scalability and relevant routing that a Pub/Sub messaging service can accomplish.
Pub/Sub methodology is also used in microservices architecture. Microservices are a collection of loosely coupled, decentralized, and independently deployed data. An example of a platform built off microservices would be Netflix.
PubSub messages are behind so many interesting and useful real-time technologies. They can be used to power live dashboards during virtual events, to move players in a mobile game, and to turn home devices (like a thermostat or security system) on and off from your phone. The possibilities when using Pub/Sub are endless.
The most prominent issue with Pub/Sub communication actually stems from one of its biggest advantages, the decoupling of data producers and their receivers. Failed message deliveries can be an issue with Pub/Sub services, since there is no connection or communication between them. Publishers do not know if their messages reached all subscribers, and subscribers cannot know if they are receiving all communications from a publisher.
Subscribers must assume that they are receiving all published messages, which can cause issues if they miss certain information. This is a well-known concern that can have disastrous effects, and different APIs aim to fix this issue with additional parameters. Using a message broker also helps to guarantee message delivery.
Without additional checks and balances, instability can occur when a Pub/Sub program scales quickly. This can run the risk of a load surge, which is when the number of subscriber requests saturate network bandwidth for a period of time, and causes a slowdown.
The Pub/Sub paradigm can be unnecessarily intricate for smaller scale operations. If it is unlikely that a program will need to scale exponentially, other methods like polling may be better suited for the use case.
The Pub/Sub messaging paradigm is one of the core foundations to PubNub’s real-time technology. Our technology relies on the unique ability to publish and deliver any volume of messages within 100ms. This allows products to reliably stream data, update live dashboards, broadcast chats, and so much more.
PubNub is a real-time communication platform that helps build applications with a selection of APIs and SDKs. We can also integrate with most stacks, languages, and third-party APIs. The PubNub Data Stream Network offers global scalability and unmatched reliability.
It is super simple to implement Pub/Sub messaging using a PubNub framework. We have also published multiple documents, like this Quickstart, that assist with programming a messaging application.
If you are interested in speaking with one of our experts to create or configure an awesome, reliable real-time communication system, contact us here.
