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:
Which of the above service is intended for Event Sourcing?
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
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.
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.
