Publisher-Subscriber Model (Pub/Sub Pattern)
What is the Pub/Sub Pattern Model?
The replacement of monolithic applications with applications developed with microservice architecture has brought about new communication models on the internet. The pub/sub pattern, an architectural design pattern, also enables scalable messaging and information transfer. In this article, we will focus on the details, advantages and usage scenarios of the pub/sub pattern concept.
The ARPANET, which is considered the pioneer of the universal internet, paved the way for communication with multiple machines over a single communication line with the method of packet distribution. Since then, the internet has been a means by which devices and people in remote locations can communicate and transfer information. Today, the Internet is still used for the same purpose, but the scales have changed, are changing.
The access of billions of people to the internet changes software development processes and brings new methods of communication. Monolithic applications are being replaced by applications developed with microservice architecture, databases are being moved to cloud platforms with this change, and communication patterns connecting people and devices at both ends of the internet are being renewed in parallel with this change. The pub/subscriber pattern is one of the central models of scalable messaging and internet communication.
As Global IT, the oldest and only Premier business partner of Google Cloud in Turkey, we will try to explain the publisher / subscriber model in this article. We’ll focus on the definition of a pub/sub pattern, its uses, and how it works.
What is a pub/sub pattern?
The publisher/subscriber or pub/sub messaging pattern is a design pattern that provides a framework for message exchange between message sender (publishers) and receivers (subscribers) that allows for connection and scaling on the topics they subscribe to. Messages are sent from a publisher to subscribers as they become available. Broadcasters broadcast messages (events) to channels (topics). Subscribers can also sign up when they want to receive messages for topics they are interested in.
This is different from the standard request/response model underlying Internet communication. The pub/sub offers the optimal framework for real-time data streaming and makes it possible to create dynamic networks at internet scale. The pub/sub pattern, which emerged from the need to scale out information systems, offers an architectural approach that responds to the need for systems to scale dynamically, with the massive adoption of mobile and IoT devices and the expansion of web-based applications.
Let’s consider a telephone exchange. If there are 100 telephone subscribers, 100 input lines are needed in the telephone exchange, and as the number of subscribers increases, the switchboard must create a new input line for each new subscriber. This situation, which can be called static scaling, does not seem possible with today’s conditions.
In contrast, a phone system running in the cloud has the ability to allocate servers and entry lines based on traffic. This system, which can increase or decrease server resources to handle the change in traffic, can use resources more efficiently through dynamic scaling than static scaling.
How does the pub/sub pattern work?
In the pub/sub messaging model, publishers do not send direct messages to all subscribers; instead, messages are transmitted through intermediaries. Publishers don’t know who the subscribers are or what topics they subscribe to. This means that the publisher and subscriber processes can work independently of each other. This model, known as loose coupling, serves to eliminate service dependencies in traditional messaging models.
The publisher/subscriber model allows highly dynamic networks to be built at scale without incurring overload and unnecessary costs. The pub/sub model, which is preferred from use cases such as event messaging, instant messaging, or live data streaming, is also used for workload balancing and asynchronous workflows.
A simple information system generally follows the following model: Input – processing – output. In this stream, the system needs more than one input and output module to handle concurrent requests. On the other hand, it is also a problem to redirect messages from the input section to the relevant output module.
An addressing mechanism is needed to eliminate these routing problems. Given that at the scale of the Internet, systems have to process thousands or even tens of thousands of simultaneous communication requests, systems have to solve the following problems:
● Distribution of load among multiple processing modules due to high volume and geographical spread
● Fulfillment of predefined addressing between modules
The pub/sub model solves these problems by using a data line through which people and internet-connected objects can send and receive messages. Let’s consider social networks. When you want to get a share to your followers on Facebook or Twitter, you don’t have to post to each of them separately.
As a streamer, you deliver your message through a single channel, and those who subscribe to you will see it. You don’t need to know how many followers you have, how to communicate with them. Because the pub/sub model does it for you.
What are the benefits of the publisher/subscriber model?
We think we have given some of the answer to this question in the areas we mentioned above, in the areas where we talked about scalability. Of course, the pub/sub pattern offers advantages beyond that. We itemize these advantages below.
Less responsibility for publishers: Publishers who want to get their message out to audiences don’t have to think about subscriptions when creating publishing modules. The publisher is solely responsible for providing accurate data outputs via the API, even without any knowledge of the number of subscribers, their identity or message types. When a change occurs, the model communicates that change and new value to the relevant subscribers.
Less burden for subscribers: The pub/sub pattern delegates the responsibilities of both parties in the publication/subscriber relationship to the API. Publishers don’t have to think about the technical details, and subscribers don’t have to think about the inner workings of publishers. Subscribers can only communicate using the publisher’s public API.
Real-time communication: The pub/sub delivers messages to subscribers instantly via “push”-based distribution, providing the ideal option for largely real-time communication requirements.
Increased scalability and reliability: The pub/sub messaging model is the foundation of the modern internet and is a flexible solution. It is not necessary to define a certain number of publishers or subscribers in advance. Depending on usage, publishers and subscribers can be added to a required topic. For example, how many people follow a topic is irrelevant in the pub/sub pattern, as this model promises simultaneous submission to all recipients.
Ease of development: The pub/sub can be easily integrated without depending on the programming language, protocol or specific technology. This model also acts as a bridge to enable communication between components created using different languages.
Separated/loosely coupled components: The pub/sub allows to easily separate communication and application logic, thus creating isolated components. In this way, developers can create more modular, robust and secure software components. It can also improve code quality and sustainability.
Pub/sub pattern usage scenarios
Let’s talk about retail and delivery logistics. The pub/sub is a widely used model in delivery logistics. At a time when package deliveries are becoming more widespread, logistics companies need to use delivery resources more efficiently. To optimize delivery, dispatch systems need up-to-date information on the whereabouts of their drivers.
Event-based pub/sub messaging gives logistics companies this capability. With real-time access to drivers’ location information, central offices can better predict arrival times and develop routing solutions.
In addition, the pub/sub is also used to notify cancellations, new orders. In such a system, everyone subscribes to the topic that interests them. Drivers can subscribe to traffic and route information, while shipping and ERP systems can subscribe from completed delivery updates. Tracking and dispatch systems can track live location updates.
The pub/sub pattern is preferred for such operations as well as use cases such as instant messaging, data flow, workload balancing, and asynchronous workflows.
Explore the details of the publisher/subscriber model and Google Pub/Sub with Global IT
As Global IT, we stand by businesses with years of experience in how to use the publisher/subscriber pattern for different businesses in different industries. We’ve been focusing on Google Cloud solutions for 16 years, seamlessly delivering Google’s solutions that enable businesses to grow in the cloud. With our customers who receive their return on investment in a short time, we sign another success story in every project and adapt the advantages offered by the Google Cloud solution family to their business needs.
If you’d like to learn more about our Google Cloud Pub/Sub offering data analytics and discover what Global IT can do for your cloud transformation, you can contact us using the form at the bottom of this page.
