Structure of a CQRS event store

13
votes

I'm currently trying to understand how to build the internal structure of an event store. What I got so far:

  • An event store has two tables (collections, ...), one for aggregates and one for events.
  • The aggregates table contains the following data: aggregateId (which will probably be a GUID) and the aggregateVersion (which is an integer that simply represents the number of the last event that influenced this aggregate).
  • The events table contains the following data: eventId (again, a GUID), aggregateId (which the event belongs to), payload, and a version (which is simply an integer that describes the order of the events).

Is this correct so far? Should events be ordered by using an integer? Or should they be ordered based on a timestamp? What are the advantages of each? What are the disadvantages?

4
cqrsevent-sourcing
I'm also considering the integer (auto incremented by database) versus a timestamp question. An auto incremented database id is obviously guaranteed to be absolutely unique, but it might make recovering from some failover scenarios impossible or at best difficult. - Kimble

4 Answers

10
votes

I would suggest you to have a look at Jonathan Oliver's EventStore for reference.

In the SQL persistence version there's only one table. You could easily live without the aggregate table and store the aggregateId in the events table. The latest version could be retrieved by using a max() query.

Other than that I think you should consider having headers in the events table, cause there are always interesting metadata that you don't want to store in the events themselves.

And also, I think you should add a date column in the events table.

Finally, you probably want to have some sort of flag that states if the event has been dispatched downstream or not. This addition enable you to write in one thread or process and dispatch in another.

Aaand there, I have sort of suggested the structure of Jonathans EventStore.

4
votes

I can't add much to Mikael's answer.

Here's just one more thing as a reference: A few years ago Greg Young wrote down his thoughts about an event store implementation. The document can be found at http://cqrs.wordpress.com/documents/building-event-storage/

Although I believe his approach has evolved in the meantime as well.

2
votes

Aggregates have to do with cqrs but not directly with an event-store. You're right there are two collections but these are events and snapshots. For more details look at: https://github.com/jamuhl/nodeEventStore