Azure Event Grid brings together Event Publishers and Event Handlers in a loosely coupled manner, by providing a serverless and event-based routing service.  This blog describes some of the main characteristics an event handler should have in order to fit into this communication model.

Requirements

Availability

Data is pushed towards the event handlers, so they need to obtain a minimum level of availability.  The event handler must expose an HTTP endpoint that can be consumed by Azure Event Grid.  If the endpoint is not reachable, a back-off retry kicks in that lasts for 24 hours, which weakens the high availability requirement a little bit.

Scalability

The event publishers determine the pace in which events need to be processed, because Azure Event Grid immediately forwards these events with minimal latency.  This means that event handlers need to dynamically scale their processing power, in order to handle peak loads without interruptions.

Intelligence

Event handlers should be rather smart endpoints.  For example, they need to be capable of dealing with out-of-order messages.  They must understand the sequencer event fields to determine the right order of events on any particular object.  Azure Event Grid doesn’t care about ordering between event messages!

Serverless Façades

A highly available, highly scalable and intelligent application: this smells like serverless technology, which is a perfect fit for event handlers!

But… What if your final backend application / service does not meet these requirements?  Are you doomed not to use Azure Event Grid at all in such scenarios?  No!  In these cases, you can put a serverless event handler façade in front of the actual event handler.  This façade can fulfil one or more requirements that the backend system does not support:

• Availability: the façade can transform the message exchange into an asynchronous protocol (e.g. Azure queues or FILE/FTP), which does not require the event handler to be available all the time.
• Scalability: the façade can transform the message exchange into an asynchronous protocol (e.g. Azure queues or FILE/FTP), which load-levels high peaks and allows the event handler to process events at its own pace.
• Intelligence: the façade can deal with the sequencing requirements and offer the events in the correct order to the final event handler.

Conclusion

Event handlers preferably need to be available, scalable and intelligent.  Serverless event handler façades can overcome potential shortcomings of your final backend application.  If the majority of your backend event handlers does not meet these requirements, you might consider other solutions.

Don’t hesitate to share your vision on this!  It’s recent technology, so looking forward to new insights!

Cheers,
Toon