BT

The Basics of Event Sourcing and Some CQRS

| by Jan Stenberg Follow 29 Followers on Sep 30, 2014. Estimated reading time: 2 minutes |

The ideas of event sourcing are not new, systems were typically built this ways in mainframes before SQL databases came along and databases works with event sourcing internally, Greg Young explained in a recent presentation.

Working with algorithmic trading Greg, lead architect for Event Store and creator of the term CQRS, realised they needed a deterministic system with an audit log which was proven to be correct, common in many regulated industries. From this he came up with an idea:

State transitions are an important part of our problem space and should be modelled within our domain

Modelling this way using events Greg has found that a lot of problems in a domain will go away and notes that within industries like finance, banking or insurance no one is using the concepts of current state. A reason for working so is a need to keep everything that happens; events are never updated or deleted, they are immutable. When an error occur a reversal, cancelling the original event, then applying a new correct event is made. He also emphasizes that the same strategy is possible for any form of current state; make it transient and derived from all events.

Two advantages with event sourcing from a developer’s perspective Greg mentions are:

  • Since events are immutable it’s a model that’s very easy scale up, the events can be cached, copied and distributed without any problems.
  • Smoke testing is a series of test simulating real usage of a system trying to ensure the system will work in production. Saving all commands it’s possible to rerun all commands ever processed comparing the results with earlier runs with respect to expected changes, which will give a very high degree of confidence the system works as expected.

Overall Greg finds event sourcing a great transactional model for many businesses, being append only and immutable. A problem though is queries like finding all users with a specific name which can be awkward, comparing it with always doing a full table scan in a SQL database. This is where CQRS becomes interesting, separating writing from reading and enabling queries using a separate optimized read model for that kind of queries. It’s also possible to have multiple read models for different kind of queries, e.g. a document database and an OLAP cube.

Greg concludes with:

A single model cannot be appropriate for reporting, searching and transactional behaviours…

Rate this Article

Adoption Stage
Style

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

Event Store for Algorithmic trading by Shashank Jain

Hi Greg,
Is EventStore a good fit for Algorithmic trading

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

1 Discuss

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


Recover your password...

Follow

Follow your favorite topics and editors

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

Like

More signal, less noise

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

Notifications

Stay up-to-date

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

BT