What is the Publisher Subscriber Model?

Microservices benefit from loose data coupling, which is provided by a publish subscribe model. In this model, events are produced by a publishing service and consumed by downstream services.

Designing the micro service interactions involves event handling and consistency checks. We look into a pub-sub architecture to evaluate it's advantages and disadvantages compared to a request response architecture.

This type of architecture relies on message queues to ensure event passing. An example would be rabbitMQ or Kafka. The architecture is common in real life scenarios and interviews.

If there is no strong consistency guarantee to made for transactions, an event model is good to use in microservices. Here are the main advantages:

00:00 Problem Statement
00:49 Asynchronous Events
01:58 Publisher Subscriber Model
03:04 Advantages of Event Systems
05:45 Drawbacks of Event Systems
10:22 Conclusion
11:22 Thank you!

1) Decouples a system's services.
2) Easily add subscribers and publishers without informing the other.
3) Converts multiple points of failure to single point of failure.
4) Interaction logic can be moved to services/ message broker.

Disadvantages:
1) An extra layer of interaction slows services
2) Cannot be used in systems requiring strong consistency of data
3) Additional cost to team for redesigning, learning and maintaining the message queues.

This model provides the basis for event driven systems.

Looking to ace your next interview? Try this System Design video course! 🔥

Course chapters:
1) Design an email service like Gmail
2) Design a rate limiter
3) Design an audio search engine
4) Design a calling app like WhatsApp
5) Design and code a payment tracking app like Splitwise
6) Machine coding a cache
7) Low level design of an event bus

The chapters have architectural diagrams and capacity estimates, along with subtitled videos. Use the coupon code of 'earlybird' to get a 20% discount.

References:

[spicytuna]

In your example at 9:00, the business logic of transfer and transfer fee is tied down to each other. so this biz logic cannot be broken down to 2 microservices in first place regardless of event driven service or pub/sub service is used.

[josephloso]

you are among the best youtube teachers I have encountered simple and very easy to understand

[spicytuna]

thank you for enlightening me about this system design. i have a comment on the arrows. those arrows supposed to be bi-directional since requests go into one direction and responses go to another direction. looking forward to your videos. thanks again.

[ayasswain]

Very nicely explained. Publish subscribe model is also used for order fulfillment by many companies when users place orders online to buy their products.

[sdfg]

Nice and complete explanation,
some examples where they are used:
1) all notifications work this way.

2)Event driven systems are particularly lightweight, so they are extensively used for Notifier hardware(sensors) with minimal processing power/ power consumption, to broadcast events whenever their is a malfunction/low battery.

3) they are mainly used for systems which are not inherently in requirement of security, though some kind of crypt might get used to ensure the source of msg to be valid.

4) not particularly a point but, should have mentioned youtube's own publisher-subcriber system while putting a video on youtube ;-)

[sankalparora]

Very clean and very precise - knew about it but the video made it clearer. Thanks.
Great work sir!

[jimhewes]

I’ve watched a couple of your videos so far. Very good job! I enjoyed them. At 8:56 you mention that you’ll be dealing with ways to avoid the out-of-order problems (consistency, I guess) in a later video. Have you made that yet? If so, where is it?

I’ve been interested in general message passing systems for a long time because of the loose coupling aspect of it. That’s what attracted me to the Actor model. But in trying to write some small programs with the Actor model (for example I use the C++ Actor Framework) I run into problems with out of order messages similar to what you’ve described here. The nice thing about the model is that each actor is a single thread, making it easier to reason about and avoid deadlocks. But according to the theory, messages are not necessarily in order within the system. So it seems as if it’s really just pushing the complexity of the problem of deadlocks into the realm of message order.

What I’m looking for is general patterns, techniques, etc. for dealing with out-of-order messages. Or I should say, dealing with cases where messages need to occur in a certain order within a system. If you know of any resources let me know since I haven’t found any so far.

[kvaranovich]

Wow, I liked the explanation a lot. Thanks!!!

[oykfwrl]

Thank you, hope i can finish watching ur videos soon so much good quality videos love u

[tsndiffopera]

Coherent and lucid explanation. Thanks for the video. I am subscribing to you. :)

[anastasianaumko]

Thank you for your work! 😌 Very educative

[chithraprakash]

Great explanation. Very useful video. Thanks for sharing

[rajumondal]

almost everytime u give a hint of the next lecture its great

[schan]

Thanks for the video. I really enjoyed it and I really liked your presentation.

[qbmain]

very useful video, thanks for explanation!

[sugyansahu]

Great video. I was expecting this publisher subscriber thing.
Moreover, you can also cover publisher-subscriber design patterns also.. which is using the object oriented model.

[rarindam]

Very good explanation of failure is a bit wrong from POV of design....on can simpy argue just by redesigning so that S2 only sends a message after it has processed, SO takes the commission out, then the design is not going to have the problem stated.
But kudos to you for explaining this is so much clean detail.

[Bala-gocc]

Good video. It helps me to understand better.

[dilawarmulla]

Amazing explanation! Continue making videos on system design.

[raj_kundalia]

Watched on 13 Nov, 2021 - Thanks for the video.