Observer vs Pub-Sub Pattern

I was once asked in an interview: “What is the difference between the observer pattern and the pub-sub pattern?”

I immediately figured that pub-sub means publisher-subscriber and I then vividly recalled, from the book Head First Design Patterns:

Publishers + subscribers = observer pattern.

“I got it, I got it. You can’t trick me.”, I thought.

I replied with a winning smile: “They are the same.”

But the interviewer smiled back like he got me and said: “No, they are not.” And I was like: “Wait, what?”

So, what did I miss? How did it go wrong?

When I came back home, I decided to find the answer by Googling it. This post is about what I learned from that query.

Before delving into the difference, let’s first talk about the observer and pub-sub patterns.

Observer Design Pattern

I think a lot of people will agree with me that the observer design pattern is one of the easiest design patterns. I mean, unlike the other design patterns, you can at least ‘feel’ what the main concept is when you first read about it.

“The observer pattern is a software design pattern in which an object, called the subject, maintains a list of its dependents, called observers, and notifies them automatically of any state changes, usually by calling one of their methods.” — Wikipedia definition

Let’s explain it in layman’s terms.

Let’s assume you are searching for a job as a software engineer and interested in a company named Banana Inc.

So, you contacted their hiring manager and gave him your contact number. He assured you that if there are any vacancies they will let you know. And there are several other candidates interested as well.

They will let all of the candidates know about the vacancy and, maybe, if you respond then they will conduct an interview.

So, how is this scenario related to the observer design pattern?

Here, the company Banana Inc. is the Subject, maintaining a list of all the Observers (candidates like you) and will notify the observers of a certain event (vacancy).

Observer design pattern

So, if you ever need to implement this scenario in software or an application, you can follow this process and say that you have implemented the observer design pattern.

I’m not going to bloat my article by showing any code examples because there are lots of examples available on the Internet.

Pub-Sub (Publisher-Subscriber) Design Pattern

Yes, the Subject in the observer pattern is like a Publisher , and the Observer can fully be related to a Subscriber.

Yes, the Subject notifies the Observers just as a Publisher generally notifies its subscribers. That’s why most of the design pattern books or articles use the publisher-subscriber notion to explain the observer design pattern.

But there is another popular pattern called publisher-subscriber and it is conceptually very similar to the observer pattern.

The major difference between the (real) publisher-subscriber pattern and the observer pattern is this:

In the publisher-subscriber pattern, senders of messages, called publishers, do not program the messages to be sent directly to specific receivers, called subscribers.

This means that the publisher and subscriber don’t know about the existence of one another.

There is a third component, called broker, message broker or event bus, which is known by both the publisher and subscriber. It filters all incoming messages and distributes them accordingly.

In other words, pub-sub is a pattern used to communicate messages between different system components, without these components knowing anything about each other’s identity.

How does the broker filter all the messages? Actually, there are several processes for message filtering. The most popular methods are topic-based and content-based.

We won’t go any further down that road, but Wikipedia explained it well.

Pub-sub pattern (image credit: MSDN blog)

So, in a nutshell, the major difference between these two patterns can be shown like this:

Image source: developers-club

Makes sense?

Let’s list the differences in a summary:

In the observer pattern, the observers are aware of the Subject. The Subject maintains a record of the Observers. Whereas, in publisher-subscriber, publishers and subscribers don’t need to know each other. They simply communicate with the help of message queues or a broker.
In the publisher-subscriber pattern, components are loosely coupled as opposed to the observer pattern.
The observer pattern is mostly implemented synchronously, i.e. the Subject calls the appropriate method of all its observers when an event occurs. The publisher-subscriber pattern is mostly implemented asynchronously (using a message queue).
The observer pattern needs to be implemented in a single-application address space. On the other hand, the publisher-subscriber pattern is more of a cross-application pattern.

Despite the differences between these patterns, some might say that the publisher-subscriber pattern is a variation of the observer pattern because of the conceptual similarity between them.

And they aren’t necessarily wrong; they are quite similar, aren’t they?

Well, that’s all for now. Hopefully, you get the idea. Thanks for reading this article. Please let me know if there are any mistakes or if any modifications is needed. Thanks in advance.

Originally published at: medium.com/better-programming/observer-vs-p..