I’m currently architecting a solution for a client that needs to process several hundred thousand notifications over a two-hour period being sent from an internal system to a Windows Azure application. The Azure application is then responsible for notifying users through an appropriate mechanism. With the initial development, this is through push notifications to mobile applications, and for this we’re using Windows Azure Mobile Services; however we need to allow flexibility in notification delivery for the future. From the start it was obvious that the solution had to be decoupled in order that the source system (In this case a Telco billing system) was able to remain performant.
Due to the integration patterns available, the billing system needed to be able to ‘fire and forget’ the notification messages as it was processing customer data, and this meant that we must employ a queue on-premise, we also have some enterprise firewall constraints which complicate matters a little. Our solution was effectively decoupled at this point, and would have been able to cope with the load and demand. But our final architecture also includes an Azure Service Bus – why?
One of our clients requirements was to be able to provide an extensible notification framework, at present only two types of notification are to be sent to Azure, however their roadmap shows many more message types, some of which may not be delivered through Azure Mobile Services.
We deliver messages from our on-premise queue in to an Enterprise Service Bus using the Azure Service Bus, through a service which we host in Azure. One of the key properties of an ESB are the concepts of topics and subscribers, and this is the key to the extensibility and flexibility of the system which meets our client’s future roadmap.
When our service receives messages from the on-premise queue, it publishes a message with a topic relating to the type of notification. We have services which subscribe to topics, and these then can process the message in the most appropriate way. So for example, an ‘Appointment Booked’ notification could be routed to a user via an email, as could a ‘Scheduled Downtime’ notification. A service which understands email can be created, and subscribes to the topics that are appropriate. A more urgent alert, such as ‘Bill Overdue’ could be sent through a push notification to a user’s device.
The client can make a configuration change to the services which subscribe to the ESB very easily, and gains great flexibility in the way notifications are delivered. Moreover, any failure of an individual notification method does not stop these notifications being delivered through an alternative method. If we stop subscribing to ‘Alert’ topics on the ESB for example, we will still be able to process ‘Status’ messages.
In conclusion, using an on-premise queue and a Windows Azure based service bus has given us a great deal of flexibility. We’ve been able to work round some enterprise firewall constraints and provide a flexible and scalable solution which will allow our client to implement their roadmap with minimal effort or disruption.