Why are we upgrading a perfectly working notification system?

To tell the whole truth, we have to begin from our notification system history dating back to the start of this century. Yes, this was a time when you did not check your e-mails or post an update on social media while taking a bus to work/school, or while waiting in a shop queue line. Life was a bit slower in those times, and you really did not care if you received your email or SMS a couple of hours or even days later than expected; receiving notifications for the real-time activity of your bank account was wishful thinking.

Back then we had a notification system that simply did not need to work near real-time because there was no business need for it, which was due to the fact that there was no ecosystem of smartphones and IoT devices that could provide some agreeable end user experience, and terms like “event driven architecture” were not yet a thing. Back then, we had a simple, scheduled polling system; it was a good enough solution which satisfied all the counterparts because the number of messages flowing around was reasonably low.

All that started to change at the beginning of 2010s when all of a sudden internet on mobile devices became the standard. Businesses started to offer a wide variety of services and buying a movie ticket on your mobile right before going through the turnstile became possible. As bank mobile applications became widely used, it opened up a new way to notify the customer about events of interest. For us, it meant that there was a sudden increase in in-house counterparts who all wanted to push relevant information towards the customer. That led us to the point where the old notification system architecture enabled neither easy in-house onboarding nor near real-time messaging.

Dead end, now what?

The time was right for a new notification system to be born. To fulfill the need of near real-time messaging, we had to build up a new system with an event-driven architecture in mind. This is how we did it: as we were shifting from polling based architecture to event-driven architecture, we started to write the new notification system from scratch with the latest Java technology stack and started rolling out new services step-by-step, eventually fully decommissioning the old system.

Great success!

Our first goal was to provide a bank-wide common interface for easy onboarding of event producers. All these events are now being produced without knowledge of the final destination where they eventually end up, whether it is a customer smartphone, internet bank notification bar, some internal service or even some external integrated enterprise resource planning system.

The second goal was to enable customers to easily choose what type of messages they want to receive on their channel of preference. For us, it meant that we had to set up the part of a service responsible for dispatching the events towards the dedicated channel based on the customer preference. That event dispatching service helped us keep the customer contract knowledge and event flow control in a single step early in the event flow, removing the unnecessary load of events. From a high number of customer preferences came the need to have them available in a dynamic cache to speed up event processing. Today, with this horizontally scalable solution (Figure 1), we can handle the current event load with ease.

Figure 1 — Current architecture

Ok, sounds good. Prove it!

Let’s take the simple example of withdrawing money from an ATM. The precondition is that you are a user of our mobile app and have push notifications enabled for a decrease in balance. After you have confirmed the amount you would like to withdraw and before the machine starts to give bills out, you receive a notification on your phone that says a withdrawal was made in that amount.

Where to go from here?

Today our notification system is successfully delivering a wide range of messages in different formats across different devices and platforms. However, as we can see an upward trend in the volume of messages being delivered, we cannot go home and rest at ease. At some point in the future we will reach the throughput limit of messages in our messaging platform. To prevent this unpleasant situation in which our customers start receiving their messages with delay, we must start a new journey to migrate to a new messaging platform and, again, be one step ahead of demand.

Want to take part of our digital journey? See the video below and learn more about our projects: www.swedbank.ee/techjobs