In cloud-based and distributed applications, components of the system often need to provide information to other components as events happen.
Publish/subscribe messaging, or pub/sub design pattern is a form of asynchronous service-to-service communication used in serverless and micro-services architectures. In a pub/sub model, any message published to a topic is immediately received by all of the subscribers to the topic. Pub/sub messaging can be used to enable event-driven architectures or to decouple applications in order to increase performance, reliability, and scalability.
All the modern cloud-based solutions platforms come with built-in support for publisher subscriber service components.
Let’s say we want to develop a notification delivery service where servers would want to send Emails, SMS, and iOS push notifications as well. First, we will need to understand how we send notifications to multiple platforms in the first place, so let’s dig a little deeper and understand notification types.
1. iOS Push Notification
A provider sends notifications do Apple Push Notification Service, a remote service provided by Apple to push notifications to iOS devices.
2. Email Message
3. SMS Notification
Same as above, we can use services like Twilio to deliver SMS notifications.
One way is to directly couple each notification service with your backend and goes on with your lives but that would not be scalable is it? It will hit its limit as soon as the volume of requests on your backend increases. It would also increase the burden on your backend because now your backend would not only be responsible for handling HTTP requests but also sending notifications.
The solution is to decouple this entire system by creating clear boundaries of responsibilities of your backend and notification system. The initial proposal to decouple your notification system could look something like the following: