Experiences Building a Reactive Event-Driven CQRS Application

| by Jan Stenberg Follow 23 Followers on Aug 01, 2014. Estimated reading time: 2 minutes |

A note to our readers: You asked so we have developed a set of features that allow you to reduce the noise: you can get email and web notifications for topics you are interested in. Learn more about our new features.

Reactive by design and with an immutable domain model was important requirements for our new architecture, Duncan DeVore explained in a recent presentation sharing his experiences building a distributed application based on CQRS, eventual consistency and event sourcing, written using Akka and Scala.

Duncan, VP of Engineering for an energy company, describes Command Query Responsibility Separation (CQRS) as a separation of commands and queries into two objects enabling among other things separate optimization, in Duncan’s experience a very common need. Commands, although they mutate state, is not about editing data but behaviour, a request to perform a task or action, preferably transferred as a message. Queries are a thin read layer above the data store. It’s not a projection of the domain, instead data is often stored based on a fetch or screen structure, with a single key to read all data needed. A challenge separating writes and reads is eventual consistency; it takes some after a write until a read will show the same data.

The majority of business applications today rely on storing current state and this is something Duncan believes is a side-effect of the adoption of relational database systems (RDBMS). In contrast event sourcing is about capturing events, it’s behavioural by nature and does not persist current state, instead state is derived. An example where this is an advantage is a requirement for an existing shopping cart to report all order where customers removed items. For a system tracking current state this can only be done for new orders. For an event based system the events for all orders are already there, only the reporting functionality has to be added.

In mature business models the notion of tracking behaviour is very common, one example being a bank account where every transaction, e.g. deposits and withdrawals, is recorded. Current state can be trusted since it’s recreated by replaying all previous transactions and it can also be reconciled to ensure validity.

Two technology implications when working with events that Duncan emphasizes is that the storage system becomes an additive only architecture making it easier to distribute and that horizontal partitioning becomes easy since there is only a single key used for fetching data.

Duncan concludes with a quote from himself:

I Believe that CQRS and Event Sourcing when combined provide a clear and concise way to build distributed applications that adhere to the reactive manifesto

The Reactive Manifesto was published in September 2013, currently signed by over 6,300 people.

Duncan is co-authoring a forthcoming book titled “Building Reactive Applications”.

Rate this Article

Adoption Stage

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread


Login to InfoQ to interact with what matters most to you.

Recover your password...


Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.


More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.


Stay up-to-date

Set up your notifications and don't miss out on content that matters to you