Robust Architecture for Event Handling

This is about a scenario where an AWS infrastructure was used to build a decoupled, robust and highly scalable methodology to implement an event handling mechanism. In a practical scenario, we had to accurately monitor when users perform different actions our system. This article describes how we had implemented it initially, the issues we had, and how we overcame them in a later iteration with an improved architecture involving AWS.

Use cases

In many applications we see system event indications for users. This is a result of user presence handling within the application. These behaviours are really useful for the applications where the use cases depend on different users, or where a user can communicate with one or multiple other users in real time.

Following are some real world example use cases.

• In a chat application I need to see if the users that I am chatting with are online or offline.
• As a patient who recently joined a telemedicine application I need to see if the doctor that I am assigned to is online or offline.
• As a department head I need to see if my department members are online at a given time.
• Notifications for various system events are delivered in most of the web applications

Characteristics

Following are some requirements/issues that needed to be addressed in the presence handling mechanism.

• Users should be accurately and instantly shown system events.
• The number of parallel sessions for the users should not bother the mechanism.
• The use of firewalls with special rules(Ex: Firewalls that block websocket communication) should not affect the results of the mechanism.
• A system event can have a particular audience. Which means some events are not delivered to all the users in the system.

Architecture

Lets build the architecture with the requirements in mind.

First we create the components for passing events between the users

We need a decoupled way of sending events to the web application from the frontend. Lets keep in mind that there can be numerous updates to this architecture in the future. Also we need our components to be decoupled and highly available to handle the load in future.

Decoupled architecture to pass events from the API Server to Frontend

Lets have a look at the initial components of our architecture.

• 1 — Application API server

The application API server which contains the application logic. Most of the system events are generated at the API server.

• 2 — Events SQS

Events are first queued up into this queue. This is a standard AWS queue with the ability to handle a large number of messages. A Lambda function is attached as a trigger to consume messages.

AWS SQS is a fully managed, scalable queue structure which can handle thousands of messages with a high throughput. This service is often used as a service that helps decouple application components in different systems.

• 3 — Events handler

Events in the queue are consumed by this handler function. If event attributes are missing, this handler will be adding them. For example, the audience for a particular event can be set within this handler.

AWS Lambda is used to implement the handler function. SQS and Lambda can be easily integrated to implement this particular behaviour. Lambda functions are run serverless, which means that we do not need to provision resources to run the application code within the function.

• 4 — Secondary events handler

This events handler sends messages to be sent via the websocket connection. The code should be able to optimise the code to only try to send messages to websockets that are actively connected.

• 5 — WSS API Gateway

WSS API Gateway is the main communication establishment for presence handling. Websockets make pings and data delivery easy since the payloads are small and the communication is fast.

AWS API Gateway is a fully managed service that allows developers to create WSS or HTTPS APIs. This offers scalability, monitoring and security functions to manage the APIs within the cloud. Lambda functions can be the target functions for the APIs that we implement.

The websocket connection is used to send/receive pings and events from the serverless section. Now we can have the API Server to send messages to the frontend applications with a flexible and highly available component architecture.

Lets add the ability to handle database events automatically

Our application DB is a DynamoDB database. There is a feature called DynamoDB Streams that captures all the item level modifications in a DynamoDB database.

• 6 — Application DB

This is the database containing application data. DynamoDB databases have flexible schema handling capability.

• 7 — Database Event Handler

DynamoDB Streams provide us the chance to attach a Lambda function to the item level changes as a stream. We can use this as a trigger to generate events if needed.

For example, in a Telemedicine application we can let the other users know of the Doctor’s presence in the clinic by listening to the online: true object attribute change from the database.

What if the Websocket fails?

I’ve often had cases failing websockets even in the slightest network bandwidth change even though they are blazing fast and can handle small payloads effectively. Sometimes you may find randomly disconnecting websockets that are never reconnected. Also some clients may be using Firewalls that do not allow websocket connections for security reasons.

We need a way to maintain event delivery between our infrastructure and the frontend application.

• 8 — HTTP Events API

An HTTPS API Gateway is in place to host the events API to fetch events from the database in case the websocket communication fails. We do not use this method primarily because the websocket connection is fast and uses less amount of data than an HTTPS API.

We cannot use the same API Gateway since one AWS API Gateway can support one of either HTTPS or WSS.

• 9 — Events API Handler

The Lambda function that handles the API to fetch events from the database. This can be implemented to return the last set of records from the events list of the system.

• 10 — Events DB

This is the DynamoDB to store events temporarily. As previously explained, application events are temporarily saved in this collection in case the websocket connection does not deliver the events correctly.

Scheduling events to automatically clean up collections

We might experience unwanted data being clustered up in the collections that we just set up. Because as users use the system more and more, there will be more events that are generated and it might not be useful to keep the old events stored.

We can implement a delete function for every event record, to delete the information from the collection after the event has been delivered. Also we can place AWS Eventbridge to run a Lambda function periodically to clean up the events.

• 11 — Scheduled Event Generator

We should implement AWS Eventbridge to periodically initiate a Lambda function to clear the obsolete events in the database assuming that after a predefined time period, the events are not needed for the system.

• 12 — Scheduled Event Handler

This responds to the invocations from the Eventbridge and do the necessary updates to the events collection.

Benefits

Following are a list of benefits of the above architecture.

• Users can have multiple sessions and still the event deliverynwill be accurate. (Ex: Going offline from one session will not mark all the sessions as offline)
• Event triggers can be run from any part of the architecture.
• This architecture can be extended to pass any event through the system.
• Can easily log the users’ online/offline events.
• Fast event passing make sure that system state is informed to the user in near real-time.

Above structure might be useful to implement accurate user event handling into your next web application. And let me know what architectures have you built with AWS, and what improvements that you suggest for this architecture.

I am an AWS and Linux certified Senior Fullstack Software Engineer at Telzee.io. I am deeply interested in architecture concepts for the Javascript world. Please stop at the website buddhiv.io to visit my profile.

In Plain English

Thank you for being a part of our community! Before you go:

• Be sure to clap and follow the writer! 👏
• You can find even more content at PlainEnglish.io 🚀
• Sign up for our free weekly newsletter. 🗞️
• Follow us on Twitter(X), LinkedIn, YouTube, and Discord.