Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Experiences Building a Reactive Event-Driven CQRS Application

Experiences Building a Reactive Event-Driven CQRS Application

Leia em Português

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