Thread by @Franc0Fernand0

Push notifications are a very popular feature for many applications.

This is how to design a scalable push notification service: ↓ {1/13}

Push notification services are usually based on a publish/subscribe model.

Clients subscribe to different information channels or topics.

When new content is available on a channel, the servers push that information out to the clients.

{2/13}

At high level a push notification service works as follow:

1. Back-end applications (on-premises or cloud) configure the service to send notifications

2. At start-up the client applications (mobile or web browser) subscribe to a topic

{3/13}

3. The service store clients contacts and information about topics, subscriptions in a database

4. The service dispatches notifications to 3rd party services

5. The 3rd party services deliver the notifications to specific platforms (IOS, Android, SMS, mail)

{4/13}

So a push notification service needs to implement these functionalities (APIs):

- create a topic
- subscribe to a topic
- publish content to a topic
- retrieve subscribed clients
- push content to specific clients

{5/13}

From non functional point of view the service needs to be:

- highly available
- durable (no content lost)
- performant to keep delivery latency low
- scalable to support many topics, publishers and clients

Those requirements can be met using multiple microservices.

{6/13}

1. Notification service

Lightweight web servers receiving requests from publishers or subscribers through a load balancer.

They interact with:

- metadata servers to send/retrieve information about topics & cilents

- temporary storage to store content before delivery

{7/13}

2. Metadata service

A service responsible for storing topics & subscriptions information in a database.

It provides 2 benefits:

- decrease the load on the db acting as a distributed cache

- implement a clear interface to access the db, increasing mantainability

{8/13}

3. Temporary storage service

A highly-available and scalable layer ensuring the content persistence.

This is necessary to implement a re-deliver mechanism in case clients are not available.

A good way to implement this layer could be using distributed message queues.

{9/13}

4. Sender service

Servers retrieving content from the temporary storage and sending it to subscribers.

The information about subscribers can be attached to the content or retrieved from the metadata service.

This last option is useful for large number of subscribers.

{10/13}

A couple of additional considerations about this design:

1. the notification servers and senders should implement a content deduplication functionality to avoid duplicated submissions and transmissions.

2. the system should ensure an at least once content delivery.

{11/13}

A common way to get this is to implement a retry mechanism.

If the temporary storage is a distributed message queue, the retry can be implemented using a queue for the undelivered content.

Alternatively such content could be put in a system monitored by subscribers.

{12/13}

Many other considerations could be done. For example:

- how to rate limit notifications

- how to make sure that only authenticated publishers send content

- how to implement a service to gather analytic data

But discussing all these would be too long in a thread.

{13/13}

Thanks for reading!

I'm Franco Fernando and I often write about distributed systems.

If you enjoyed reading this:

✓ drop a comment
✓ leave a like or retweet
✓ follow me (@franc0fernand0) for similar content