Publish-Subscribe VS Request-Response
My personal learning notes of publish-subscribe VS request-response patterns.
What is Request-Response?
In a Request-response system, there are two parties. A server and a client. For every intent, the client will send a request to the server where it is processed immediately and a reply is returned to the client.
This model provides a synchronous communication between the 2 modules, meaning each request from the client demands a response from the server before continuing with other tasks.
Example : user changes his email address
Attributes of Request-Response pattern:
- simple to implement
- modules are tightly coupled
- low latency
What is Publish-Subscribe pattern
In a publish-subscriber pattern, there are normally three types of parties. Publishers, message broker and subscribers. Publishers will pipe messages to an message broker where they will be queued and sent to relevant subscribers who are interested in these messages.
This model creates an asynchronous communication between the publishers and subscribers, meaning each message sent from a publisher will not receive a response directly from an subscriber, but the message is instead being acknowledged by a broker and the broker will then forward the message to multiple relevant subscribers.
Example : User buys apples on e-commerce site
Attributes of a Publish-Subscribe pattern
- less easy to implement
- modules are loosely coupled
- slightly higher latency
How do we optimize this pattern so subscribers are not wasting resources processing messages they are not interested in? By using topics. Topics are broad categories used to categorize messages. Think of them as an enums for subscribers to filter through. Subscribers do not have to process every single message, they just have to listen for to the topics relevant to their service, and the message broker will push the relevant messages to them. Imagine an e-commerce site. The customer's email service wouldn't need to receive any messages whenever a new merchant signs up for an advertisement banner.
How do we build a robust publish-subscribe communication
We need a mechanism for failed subscribers to receive messages that they missed during their down-time. When a subscriber recovers, they should be able to replay any messages sent during their down-time. This principle is Message persistence. Not all scenarios requires this. Let's take a static web application that displays the current score of a football match. It doesn't need to process every single message but the latest message in the queue. When it just recovered from a failure, it can just wait until the new messages comes in.
But what happens during a broker failure and messages will be lost before they reach the subscribers? We have to store messages beyond runtime and use techniques like redundancy and backups. This concept is the Message Durability principle.
References and learning materials:
- https://aws.amazon.com/blogs/compute/benefits-of-migrating-to-event-driven-architecture/
- https://levelup.gitconnected.com/difference-between-publish-subscribe-and-request-response-model-d0aa9f51cf3d
- https://aws.amazon.com/pub-sub-messaging/
- https://blog.logrocket.com/nodejs-pub-sub-messaging-brokers/
- https://cloud.google.com/pubsub/docs/overview