REBEL SOURCE
GuideFeedback

Content

Introducti ... Synchronou ... Conclusion
Avatar image of Mario Škrlec

Concurrent observer pattern in Go

In this blog post, we will take a look at the observer pattern and try to make it a little bit better by making it concurrent.

godesign_pattersgolang
Concurrent observer pattern in Go

Image provided by Unsplash from Getty Images . Download the image and support the author!

Introduction

I will not try to explain what the observer pattern is and how it is implemented. A great explanation can be found refactoring.guru. Instead, I will implement the sync version and then the concurrent version without changing the interface of both Subject and Observer

Also, mind you that, for our particular use case that we will be examining, a simple single worker goroutine might be a better option. We will get to that later. 

Synchronous implementation

The most simple implementation, as described in the article above, is first creating our types. Then, our concrete implementation. This is not complicated, so I will just leave it for you to study it in the code block below. 

We create our product Subject with a single product. In a real world scenario, that product could change availability or it could be broken so every customer that has anything to do with this product must be notified. The problem with this implementation is that every time we want to notify our customers, we would have to wait for all the customer instances to finish what they are doing. This might be sending an email, working with the database or calling some external API. These operations might be time intensive and we might not want to wait until they are finished. What we want is to change the implementation to not blog our main thread. 

Let's do this with a few simple tweaks. 

First, we will modify our Notify() method. This method will spawn a goroutine that will send the product to all observers. 

In our customer, we will add a listener channel that will listen to product changes without changing our observer interface. 

All we are doing here is creating a spawn() method that listens to changes that the subject has made. Nothing less, nothing more. You can see the full implementation below:

Conclusion

This is a pretty straightforward and a simple implementation. The problem is, what if we have thousands of products that need to be notified to thousands of customers? In my opinion, this pattern does not solve that problem. A worker pool might be a good idea for this type of issue. An even better solution is to use something like RabbitMQ or Kafka for many-to-many publish/subscribe issues. 

Avatar image of Mario Škrlec
Like
Tweet
Share
Copy link

Hello, visitor.

This blogging platform is created specifically for software developers. We aim to support many more programming languages and development environments but for that, we need your support. If you like this blogging platform, consider using it to write your blogs.

We tried to make your experience of creating blog as painless as possible soSign in and give it a try.

REBEL SOURCE

Guide

RebelSource 2022. All rights reserved.