Event Sourcing and CQRS on Azure serverless functions - Part 3
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.
The event sourcing system we have built so far (in part ) only supports simple commands executing on one entity at a time. For a more realistic system we need to expand that to allow for complex multi-step commands and set based commands and queries.
Multiple step command
A command can be routed into the system by event grid and this is used to trigger a serverless function but rather than the function performing all of the work it kicks off an Azure Durable functions orchestration.
Each step is implemented as its own durable function action and the results of these are written to an event stream created specifically for this command instance. In this way the progress of the command can be queried by running a projection over that command's event stream which is independent to the orchestration event stream (which is maintained by the Durable Functions library).
Batch commands
Another scenario where durable functions come into their own is where we wish to perform the same command over multiple entities in a batch.
This is done by getting the identities of all the entities that you wish to perform the action(s) and then using the fan-out method to run orchestrations over them all in parallel.
When all these sub-orchestrations have completed, the top level command orchestration will return as complete.
Multiple step/multiple entity queries
Another process that is more difficult in serverless event sourcing based systems is multiple step and/or multiple entity queries. These involve getting the projection state over the event stream of multiple entities and then perhaps performing some aggregation step upon them.
In the same way as with a command, a query request can be routed into the system by event grid and this is used to trigger a serverless function. For a query this can include return addresses to pass the answer of the query back to when it completes.
When the query has got to the stage of requesting data a projection request is written for each projection needed, to the event stream backing that query instance. This raises a notification (as discussed in part 2) which the projection handler can respond to and write the answer back.
Then when there are no outstanding projections remaining the query can move on to any aggregation or processing steps before returning the results.
References
The source code for this project (C#) is available here, and the slides from the (furloughed) presentation are on GitHub here.
Let me know if you have any feedback or queries. Thank you for lending me your time.