What is Pub/Sub messaging?

Publish Subscribe messaging is a software design pattern for an API that describes the flow of messages (send and receive) between applications, devices, or services in terms of a publisher-to-subscriber relationship.

How Does Publish/Subscribe Work?

Pub Sub (or Pub/Sub messaging), as it is often called, works like this: a publisher (any source of data) sends messages out to interested subscribers (the receivers of data) using live-feed or real-time data streams known as channels (or sometimes called topics). All of the subscribers to a specific publisher channel are immediately notified when there are new messages received on that channel, and the message data (or payload) is received together with the notification.

The Publisher-Subscriber model allows for messages to be broadcast to different subscribers asynchronously. This asynchronous communication and event-driven architecture decouples the message delivery between the providers of data (the publishers) and the end-users (subscribers of the data). This data streaming model enables more flexibility and is not blocking like a messaging queue or some other point-to-point managed services for messaging. 

As a general messaging pattern that can be implemented across various programming languages and platforms, Pub Sub has a few core principles that are universally useful. These are:

• Applications built with a pub/sub pattern have separate communication and application logic. This makes it simple to have microservice components that are robust, secure, and optimizes being maintainable.

• Publishers do not need to know anything about their subscribers, and subscribers only have to know the name of the topic channel they are subscribed to. Publishers simply define what data goes in which channel and transmit the channel data once only from one-to-many, so that it can be easily and asynchronously shared out amongst other apps for their own uses.

• Any publisher may also be a subscriber and data streams can be multiplexed, enabling the creation of interlinked systems that mesh together in an elegant, distributed, and internally-consistent manner.

• Since intercommunication is based on event-driven architecture and based on notifications, there is no need for client-to-server polling techniques. This means less latency and more scalability. 

• Published message data types can be anything from strings to complex objects representing text, sensor data, audio, video, or other digital content.

In ordinary usage, particularly in IoT, automation, network operations, or distributed cloud environments like Google Cloud, there is often a need for an intermediary layer called a message broker or a messaging system that handles the distribution and filtering of messages, and also provides a low-latency messaging service over dedicated network infrastructure.

Why use a Pub/Sub messaging service?

Modern serverless applications and services are often decoupled into smaller modules, microservices, or sub-systems that are easier to manage dependably and more fault-tolerant. The Pub/Sub model is ideal for distributed design patterns because of real-time event notifications. 

A managed message broker or managed messaging service offers a unique advantage with the Pub/Sub model. Since the applications built with a pub/sub pattern have separate communication and application logic it enables developers to optimize for the development of their applications without working on the communication. There is no need to hire a DevOps team to manage servers on AWS, no need to build your own communication APIs, and no need to worry about a dependency on your own communication API if it doesn't scale. 

Using a Pub/Sub messaging service makes a lot of sense for developers in many use cases:

Pub/Sub messaging services offer SDKs on many platforms and languages so it is easy to find one applicable to any project and easy to build projects that use multiple languages. Pub/Sub messaging systems also offer a lot of development flexibility. For example, suppose your starting application only needed basic chat functionality. You could build chat with Pub/Sub and then easily add more features than just chat by using Pub/Sub to power other features as well. You can use pub/sub for geo-location, virtual events, push notifications, IoT, data streaming & dashboards, and more.

• Some messaging services, like PubNub, have multiple global points of presence. Data is in a high replication and eventually consistent model. Data is simultaneously duplicated to other areas so that if one of the regions and hardware fails, the network is still running. Messaging services like PubNub are fault-tolerant and risk-free because of this replication.

• Messaging services handle the scaling for you. With services like PubNub, you can have unlimited users and if your app grows by millions of users every day you’ll still not have to worry about scaling. Messaging services handle routing and optimization for data streaming between publishers and subscribers. If you were to build a service like this yourself, it would take loads of time and human effort to make it scalable unless you dedicated more time and effort than is possible for most projects.