Building Scalable Facebook-Like Notifications

Sometimes we want the server to notify the client on changes. This is something that is not possible in traditional HTTP web applications. In traditional web applications, the client has to establish a connection with the server and then waits for the response from the server. This is the problem that server-sent event is solving. The Idea behind server-sent event (SEE) is the client subscribes to stream of updates generated by the server and, a notification is sent to the client, whenever a new event occurs.

Before we go deep into SEE, let’s first understand the other possible solutions and their limitations:

Polling is a technique where the client repeatedly polls the server for data, if there are no updates from the server, an empty response is returned. The limitation of polling is extra polling creates a greater HTTP overhead.

Long polling is a variation on polling. In long polling, if there is no updates, the server holds the connection open until new update becomes available. When new data becomes available, the server responds, closes the connection, and the process repeats. The limitation is the implementation of this technique requires hacks such as appending script tags to an ‘infinite’ iframe.

WebSocket is a protocol, provides a full duplex, bi-directional communication between the client and the server. It is not really a limitation but it is more than what we want, having two-way channel is more attractive for messaging apps, multiplayer games, … etc.

The use case

Let’s dive into server-sent events through building a Facebook-like notification, the below video shows what we are going to implement.

We will develop a notification service, that provides an endpoint for a client to subscribe to a notification channel and, another endpoint to send a notification, then the service should notify the subscribers.

Implementing the notification service

Looking into NotificationController, the first endpoint that the service provides is the subscription.

It creates an instance of the SseEmitter, saves it and, returns the instance to the client. This way it keeps a connection open between the server and the client.

The notification service keeps the emitter instance in the memory, let’s check the code below.

It saves all the active instances in an array, and before adding the emitter to the array, it sets onCompletion and onTimeout callbacks, which removes the emitter instance from the array.

The second endpoint that the service provides is the send notification.

It just calls the pushNotification method.

Let’s look into pushNotification method implementation.

It calls the send method for each saved emitter to push the notification for the client. Notice, it sets the username as an event name, so that the client can display the notification for specific user (logged in user).

Implementing the client

To subscribe to the event stream, create an object from EventSource and pass the URL of the subscribe endpoint.

You can optionally listen to open and error events, then at line 15–18, it listens to the event that named with the logged-in username, hence, it displays the notifications that belong to the logged-in user only.

You can find the complete code here.

The scalability

The above solution works fine for single instance service, but if there are multiple instances are running, they have no way to communicate with each other. And when a new notification is sent, some subscribers might miss the notification depend on where send notification request landed, to better understand, let’s have a look at the diagram below:

If User C, send a subscribe request and the LoadBalancer redirect it to service B, and User A sent a notification to User C but the request landed in service A, then User C won’t get the notification because the emitter instance for User C is stored in Service B.

Redis Pub/Sub to rescue

To solve the scalability problem, we can rely on Redis Pub/Sub feature. The instance that has received the send notification request, will send a message to the Pub/Sub and notify the other instances, so each can notify their subscribers.

Implementing the scalable notification with Redis Pub/Sub

Before I start the implementation with Redis Pub/Sub, it is highly recommended to look at the following:

• Spring Data Redis.
• Redis Pub/Sub.

As described in the previous section, we need to change the implementation of send notification method of NotificationController, when a request is received, it will publish a message to Redis Pub/Sub. The implementation should be as follow:

And the code to actually send the notification is moved to the Pub/Sub listener as follow:

You can find the complete code with Redis Pub/Sub, here.

Conclusion

We have seen that Server-Sent event is a preferred solution in case we want to send updates from server to client, and we saw the drawbacks of other solutions.

WebSocket is a good solution in case of full duplex and bi-directional communication is required between the server and the client.

Also we saw that Redis Pub/Sub can solve the communication problem between the service instances, hence, making the service scalable.