This document provides an overview of microservice architecture using CQRS (Command Query Responsibility Segregation) and Event Sourcing patterns. It defines CQRS as separating the write and read functions of an application. Event Sourcing records all state changes as a series of events rather than just the current state. The benefits include scalability, simplicity, flexibility and a business focus. Popular companies using this architecture include those needing cost-effective scaling like microservices. The author provides resources and advocates for CQRS and Event Sourcing to solve common architectural challenges.

1. Microservice
Architecture
with CQRS & Event Sourcing
Ben Wilcock
Freelance Software Architect [UK]
https://twitter.com/benbravo73
https://www.linkedin.com/in/benwilcock
http://benwilcock.wordpress.com

2. What is CQRS?
2
‘Command & Query Responsibility Segregation’
CQRS is an architectural pattern for developing software
whereby the bits of the system that are responsible for changing
the system’s state (the ‘write-parts’) are physically separated
from the bits of the system that manage views (the ‘read-parts’)
This is in contrast to CRUD architecture where traditionally the
same component has responsibility for both the reads (the
views) and the writes (the state changes)

3. What is Event Sourcing (ES)?
3
Event Sourcing uses a timeline to describe state
When Event Sourcing, state is recorded as a complete series of
the events resulting from the actions taken within the domain
These persisted events can then be used to re-establish the state
of the actors within the domain at any point in time
This is in contrast to CRUD architecture where traditionally only
the current state of an entity is stored (and not the history of
events describing how it arrived at this current state)
Event sourcing complements CQRS, but CQRS does not require
event-sourcing in order to be successful

4. What are the Principles behind CQRS/ES?
Separation of Concerns (SoC)
A design principle for separating a
computer program into distinct
sections, such that each section
addresses a separate concern
Do one thing and do it well
A philosophy at the heart of UNIX
development that leads to small and
highly-cohesive applications
Event-Driven Architecture
Also known as Message-driven
architecture, this is a software
architecture pattern that promotes
the production, detection,
consumption and reaction to events
over other forms of integration
4
Domain-Driven Design (DDD)
A software development approach
whereby the implementation is
strongly linked to the business
domain in which it’s used
Loose-coupling
An approach to interconnecting
components such that those
components depend on each other to
the least extent practicable
Event sourcing
A mechanism for persisting
application's state by storing the
history of events or changes that
caused the system to arrive at its
current state

5. What are the Benefits of CQRS?
Scalability
In mosts systems the number of reads
vastly exceeds writes - yet the architecture
rarely reflects this
In CQRS the read-side is separate from the
write-side, so each can be scaled and
performance-optimised independently
Simplicity
In most systems a single model is used to
manage, describe, store and view data
This sounds simple, but it adds complexity
as contradicting requirements (writing and
reading) must be handled by a single model
With CQRS the write-model and the read-
model can be different
Flexibility
The clear separation of methods that
change state from the methods that view
state makes change simpler
Change can be made with greater
confidence and with more predictable
effects
Business Focus
Commands are intuitive and instantly
recognisable as business related actions
In CQRS this business focus together with
Domain Driven Design can result in
applications that are more responsive to
change and cheaper to maintain
5

6. What are the Benefits of Event Sourcing?
History has Business Value
By storing events, you never discard
information that may have future value
Events allow you to see the state of the
system at any point in the past
You can use this insight to answer historical
business questions as they arise
Easy Integration
Events are also a useful way of
communicating with other systems
Integration based on events offers very low
levels of coupling as the event producers
don’t need to know anything about the event
consumers (and vice versa)
Simplicity
By saving only events, you are avoiding the
complex business of persisting complex
domain objects to a relational store -
otherwise known as the “object-relational
impedance mismatch”
Performance
Events are simple, standalone and
immutable, so you can use faster append-
only operations to store them
Flexibility
A sequence of events can be "projected" into
any desired structural representation or
"view" at any time
6

7. What does CQRS/ES Architecture look like?
Multiple views
or ‘projections’
can be built to
satisfy
disparate
client
requirements
& limitations
Integrations are
unlimited, event-based
and loosely-coupled
Interactions are
modeled as
simple
‘Commands’,
‘Events’ and
‘Queries’
Events are
stored and
then forwarded
to the event
exchange
command-side
(Rules and Behavior)
query-side
(Presentation and Facts)
7
Read-side can
be scaled,
optimised and
secured
independently
of the Write-
side
Command
processing
results in
Events being
created

8. Why choose CQRS/ES for your architecture?
Here are my Top 5 reasons to consider CQRS/ES for your architecture
1. The number of reads, queries and views usually far exceeds the number of writes,
so a separation of these concerns can make development simpler and faster
2. Events are ubiquitous; every business process has them, so modelling systems on
events and storing past events has real business value
3. Often when choosing CRUD architecture, we under-estimate the complexity of
the logic required to manage the life-cycle of our business entities - this has
major impacts later, particularly on scalability
4. Event-based integration is far easier to manage and maintain than traditional
‘canonical model’ based integration techniques
5. Having independent data projections and views is really useful, particularly if you
have multiple disparate clients that require access to similar information - such as
mobile, web, public api’s etc.
8

9. Who uses CQRS & Event Sourcing?
The CQRS / ES approach to application architecture works well with Microservices, so it’s
popular with organisations that need cost effective scaling, organisations like...
9

10. An Industry Perspective on CQRS/ES
10
CQRS [Axon] - ASSESS
CQRS can work very well in specific places.
In those specific situations, however, a lot
of work is left to the developer to properly
execute CQRS.
Axon is a framework that can help with this
on the JVM, and we’ve used it with some
success.
Although it’s not perfect, it continues to
evolve and may make much more sense
than trying to write everything from
scratch.
My Axon Sample: https://goo.gl/uGGISx
Event Sourcing - TRIAL
Event Sourcing ensures that all changes to
application state are stored as a sequence of
events.
Complementary to the capture of
meaningful business events, the technique
has positive implications for analytics in
driving greater customer insight.
Not only can we query events, we can also
use the event log as history, and as a
foundation to automatically adjust the state
to cope with retroactive changes.
CQRS/ES is still considered a new and innovative approach to software design. Here’s what
ThoughtWorks said about CQRS and Event Sourcing in their 2015 Tech Radar...

11. Hungry for more?
Check out my Axon based CQRS/ES
Microservice sample code on GitHub:
https://goo.gl/uGGISx
For a conversation about how I could help your
team to achieve great things, contact me using
the social media links below:
11
Ben Wilcock
Freelance Software Architect [UK]
https://twitter.com/benbravo73
https://www.linkedin.com/in/benwilcock
http://benwilcock.wordpress.com