Jens Rantil's blog

Posted Tis 25 Mars 2014

A follow-up on CouchDB as event store

I recently wrote about using CouchDB as an event store. One issue that I mentioned briefly was that my proposed solution would not work for a single aggregate root yielding multiple key/values in a CouchDB view:

What a view cannot do is keep track of older versions of an aggregate root.

Recently I've been revisiting this problem (because I find it fun to think about) and have a slightly different solution to propose, namely to store all events for a single aggregate in a single document. That is, make the document have a list of events. This will solve all previous requirements as well as:

One argument against this solution is that CouchDB does not support atomic document modifications. This means that a user would have to first GET the document (with all events), append the new event and then write the new document (PUT). With aggregate roots that has a lot of events this would yield a great overhead in network latencies and storage (since CouchDB is an append only database).

Good news is CouchDB has update handlers that can be used to avoid the extra HTTP roundtrip. An update handler lets you can define a URL that you make a single post to. The handler will append the new event to the list and store the updated document.

I've heard somewhere that giant lists in a single CouchDB document is not recommended. I wouldn't dismiss this idea because of that. In many domains there aren't that many changes to an aggregate root after creation. Imagine an adressbook contact as an aggregate root. I don't think I've ever made more than ten changes to a contact. At the same time, this CouchDB solution for storing event sourced aggregate roots would probably not be viable if you had 10^6 changes to an aggregate root...

Category: misc
Tags: CouchDB cqrs distributed-architecture
Dude, did you like this blog post? Feel free to drop me some bitcoins at 1Q79HGDF3ZjfCwXLAW6e7gX4DeDu2GtZ7v.

Comments