Event store in Azure

Question

As per my understanding,an event store is simply a data store for all the events. This can be anything from a relational database to NoSQL, but should be optimized for storing and querying large amounts of non-relational data.So we can use following services to store events in Azure:

1. Azure Table storage
2. Azure SQL Server
3. Azure Cosmos DB
4. Azure Event Hub

Which of the above service is intended for Event Sourcing?

Answer 1

For storing the underlying event stream both CosmosDb and Azure Table storage are good solutions - I use the latter extensively but there are good examples using CosmosDb from JET.

Event Hubs is not ideal as a backing store because in event sourcing you want to store events forever. You can, of course, forward event hub events to a persistent storage but will end up using that storage as your source of truth for the event sourcing.

Lots of implementations of event sourcing do exist on SQL Server but I prefer not to have a locked-in event schema as it adds a lot of work.

For CosmsoDb take a look at: JAT/Equinox on GitHub

For Azure table storage I have this example: EventsSourcing-on-Azure-Functions on GitHub

Answer 2

Event Hubs are more-or-less a "Pub-Sub" mechanism. You can send events to it and it will broadcast those events to whoever is listening.

Azure Table storage, SQL server and CosmosDB stores data... They each store it in a very different ways, but in the end, their job is to store the data. Each one of these technologies have "change-feed" notifications (notify a listener when data changes in a document or row), but it's not nearly as reliable as a technology that is built to produce events in real-time.

Event Hubs can store data, but for a very short amount of time... For example, you can set the TTL on EH data to 3 days. That means a message will live in there for 3 days allowing subscribers to grab that message.

You can wire Event Hubs up to other services, for example: Stream Analytics... that can analyze the data and do something with it... for example: send it to a storage mechanism such as a Data Lake.

So of all the technologies you asked about, you would probably want an Event Hub to source events.

I use them in my architectures... I have a hub that processes millions of events a day from thousands of clients with no issues in latency or downtime. They are amazing in my opinion.

Answer 3

I think Event Grid would be the service most geared toward an event-driven architecture.

But there are a lot more possible combinations. I have found that using Cosmos DB with its Change Feed to trigger Azure Functions is a great way to build events into your database and respond to any data change with specific actions.