Learning notes

Publish-Subscribe VS Request-Response

My personal learning notes of publish-subscribe VS request-response patterns.

Lim Xing Zhi

Apr 22, 2023 — 2 min read

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

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.

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: