Event Sourcing and CQRS on Azure serverless functions - Part 2
This article is part of #ServerlessSeptember. You'll find other helpful articles, detailed tutorials, and videos in this all-things-Serverless content collection. New articles from community members and cloud advocates are published every week from Monday to Thursday through September.
Communicating between domains
?Once you have a system that can accept commands and update state the next step is for that system to be able to send notifications to the outside world upon which they can act. This facilitates the style of "when X happens then do Y" reactive programming that is well suited to a serverless system.
The technology I use for this is Azure Event Grid. This is a sophisticated publish-subscribe system for events with routing and filtering capabilities.
There are two important considerations when using Event Grid in a serverless context. Firstly, as this is an always on service there is a cost even when the rest of the system scales down to zero (albeit a very small cost) and secondly the delivery guarantee is "at least once" delivery. This means that you receiving applications need to be coded to deal with the possibility that they will receive the same notification twice.
Notification types
Change-feed style notifications
When data are changed in an event sourced system there are two possible things that can occur: a new event stream may be created or a new event may be appended onto the end of a new event stream.
The same multiple level key from the event stream identity is used in forming the event type which means you can attach subscriptions at any level, and for an event being appended to an event stream the notification event type includes that event type.
The notification payload also includes sufficient detail in the payload to allow the recipient to know whether they have received this notification before or not. For a new entity that would be the fully qualified entity instance identity and for an event being appended to an event stream this would be the event stream identity and the sequence number of the appended event.
State propagation notifications
Whenever a projection has run over an event stream, a notification is sent out with the state derived by that projection. This allows for state transfer between domains (or between services) without the communication between services becoming overly "chatty".
The event type name includes the projection type so that subscribers can attach at that level - you might have a subscriber that wants to be notified about changes to some aspect of an entity's state (via one projection type) but not other aspects that would come from a different projection type.
(Part 3 covers using Azure Durable Functions for workflows and batch processes)