Last month I had chance to attend an event hosted by spring.io guys, namely conference Spring IO 2015. It was held in Barcelona and gathered 41 speakers, whose talks were around spring framework, groovy, grails and clouds. As a developer, I can hardly live without spring, so this was a perfect chance to enhance my spring-related experience. Although I was not amazed by all of the presented subjects, some talks brought my attention. I would like to quickly summarize one of those.

<a href=http://www.springio.net/inside-an-spring-event-sourced-cqrs-application-or-why-microservices-can-actually-work/”>Inside an Spring Event Sourced CQRS application</a>

You are probably familiar with concept of Command and Query Responsibility Segregation. If not I recommend this great reference. To cut the long story short, it deals with having two different models: one for writes and one for reads. The read model is user-friendly, meaning it is often denormalized for a convinient projections. Thus, it is faster. Especially comparing to traditional CRUD-based system which makes a dozens of join operations for a reader.

Eugen Paraschiv has shown his experience with using this technique together with event sourcing. Event sourcing is a concept which ensures that every change in application is related in an event. Those events are stored in a chronological order and then replayed. It was shown how CQRS-like nature of the system naturally leads to event sourcing. Having multiple reads models is easy when there is a single point of truth - an event - that we can listen to and update ourself as we want

The buttom line here is another thing. As those projections are independent of each other and rely only on domain events, we can run them in separated spring contexts. We can go further and run them in different processes and JVMs. Do you see how far it goes? Yep, we can run them on separated hardware gaining the buzzworld of 2015: microservice-oriented architecture. Starting with CQRS, event sourcing and different projections for different domain areas naturally leads there.

Event sourcing with CQRS brings another values to us. Events are immutable, simple standalone objects. Storing those is better for performance than persisting complex relational model. It is also simplification of the model - it really tells you what exactly have just happened. Events help you integrating with different systems, because they can just start listening to our events. Moreover, they can replay all the events from the beginning - meaning they can pretend being integrated ever since the first event was emitted.

This is not over yet. Event sourcing is great debugging tool. Imagine that you need to troubleshoot your application on production and check what happen say 10 days ago. With event sourcing it is super easy - you just need to replay all the events before that timestamp. Voila, you have just replicated the requested situation. One may say, that replayng millions of events is not efficient. Sure, that is a valid point, but for this reason snapshots are introduced. You can store snapshots for example once for 100 events, reducing the maximum number of events to be replayed to 100.

Talk by Eugen was one of the bests ones in the whole event. Check out summary of others that may interest you: <a href=http://www.springio.net/everything-you-need-to-know-about-java-classloaders//">Everything you need to know about Java Classloaders</a>, Designing for Distributed Systems with Reactor and Reactive Streams and Real-time with Spring: SSE and WebSockets