Synchronizing the Commands and

Queries Databases

Vladimir Khorikov

@vkhorikov www.enterprisecraftsmanship.com
 Agenda

Eventual The CAP

Synchronization
consistency theorem
State-driven Projections

Denormalized

Need a projection
 State-driven Projections

Projections

Event-driven State-driven

Sync Async
 State-driven Projections

State-driven projections
Flags in data tables

A flag per each aggregate

State-driven Projections

Student
aggregate

Course

IsSyncRequired / IsDirty
 State-driven Projections

Commands Queries

Raise IsSyncRequired

Sync

Reset IsSyncRequired
State-driven Projections

Synchronization

IsSyncRequired

Offloads the pressure

State-driven Projections

State-driven
projection

Straightforward

Easy to use

To rebuild the read database,

raise the flag for all records
 State-driven Projections

Database triggers
IsSyncRequired
Monitor all changes

Need to implement
a soft deletion
State-driven Projections

Introduce the flags in the

domain model

Add a flag to Student and Course

 State-driven Projections
public class Student : Entity {
public virtual string Name { get; set; }
public virtual string Email { get; set; }
public virtual bool IsSyncRequired { get; private set; }

public virtual void RemoveEnrollment(Enrollment enrollment, string comment) {

_enrollments.Remove(enrollment);

var disenrollment = new Disenrollment(enrollment.Student, enrollment.Course, comment);

_disenrollments.Add(disenrollment);

IsSyncRequired = true;
}
}

Event listeners in NHibernate Change tracker in Entity Framework

http://bit.ly/ef-vs-nh
 State-driven Projections

Explicit flags in the

Database triggers vs domain model

Choose triggers only if you Choose the explicit

don’t control the source code implementation by default
 Synchronous State-driven Projections

Projections

Event-driven State-driven

Sync Async
Synchronous State-driven Projections

Sync Async

Runs Runs
synchronously asynchronously

Asynchronous = Without blocking

Application doesn't wait for the sync job

Synchronous State-driven Projections

Synchronous version

Application does the projection

Increases the processing time

All changes are immediately consistent

Synchronous State-driven Projections

Synchronous projections
don't scale
Synchronous State-driven Projections

Synchronous projections

Sync Async

Indexed views Database replication

Event-driven Projections

Event-driven projections
Domain events drive the changes

Subscribe to domain events

Synchronization

IsSyncRequired
Event-driven Projections

Event-driven projections
Domain events drive the changes

Scales really well

Can use a message bus

Cannot rebuild the read database

Event-driven Projections

State

Don’t store
domain events

Impossible to derive
events from state

Transition to event sourcing

 Event-driven Projections

How should you choose the projection type?

Without event With event

sourcing sourcing

State-driven projection Event-driven projection

Align the projection strategy with the persistence mechanism

 Consistency

Having two databases

instead of one
introduces latency

May end up with duplicate records

You will still gain a lot of benefits

even with a single database
 Consistency

Ways to mitigate the

potential confusion

Uniqueness constraints

Commands database is always

immediately consistent
 Consistency

How should you query

the database during a
command execution?

Run a query from a

command handler?

Queries database might not be up to

date with the commands database
Consistency

Query the commands

database
 Consistency

Reading read the Reading read the

commands database
vs. queries database

Part of the command

processing flow

Results don't cross the

application boundaries
 Consistency
public sealed class StudentRepository
{
public Student GetById(long id)
{
return _unitOfWork.Get<Student>(id);
}
}

public sealed class CourseRepository

{
public Course GetByName(string name)
{
return _unitOfWork.Query<Course>()
.SingleOrDefault(x => x.Name == name);
}
}

Serve the commands, not queries

 Consistency

You are not able to efficiently

query the current state with
Event Sourcing

Have to query the read database

Eventual Consistency

Train users not to expect

data to be immediately
consistent

Wouldn’t the software

become less usable without
immediate consistency?
The concept of immediate
consistency is
counterintuitive.
 Eventual Consistency

Are changes in the real world

immediately consistent?

The real world is inherently

asynchronous and eventually
Driver’s license consistent

Users quickly learn the concept

of eventual consistency
Eventual Consistency
A consistency model which guarantees that, if no new
updates are made to a given data item, eventually all
accesses to that item will return the last updated value.
Eventual Consistency

Display helpful
messages and set
proper expectations
Eventual Consistency

“Student registration
is submitted”

Display the new

record locally

Two-way
communication
 Eventual Consistency

Separate database Eventual

for reads Consistency

Starbucks doesn't use two-phase commit

http://bit.ly/starbucks-cons
 Eventual consistency is
problematic when the cost of
making a decision based on
the stale data is high.
Eventual Consistency

Introduce versioning
 Eventual Consistency
Update Alice

Commands Queries

Update Alice Alice

UI

Make the version number part

of all the communications
 Eventual Consistency

Check
current ver.

Commands Queries

Update Alice,
current ver.: 1 Alice v1

UI

Make the version number part

of all the communications
 CQRS and the CAP Theorem

Distributed monolith Consistency Relational database

Partition
Availability
tolerance

Reads and writes are out of sync

CQRS and the CAP Theorem

Finding a proper balance is hard

CQRS allows you to make different

choices for reads and writes
 CQRS and the CAP Theorem

Writes Reads

Give up full
Full consistency
consistency

Give up partition
Partitionability
tolerance

Consistent changes are

Scalability is important
important
 Synchronization between commands and
queries
State-driven projection
- Introducing an IsSyncRequired flag in
aggregates
Summary - Database triggers or explicit in the model
update
- Choose the explicit route by default
- Synchronous and asynchronous

Event-driven projection
- Using domain events to build the queries
database
Without Event Sourcing: use state-driven
projections

With Event Sourcing: use event-driven

projections
 Immediate vs. eventual consistency
- Immediate consistency is contrary to the
real world experience
- People pick up eventual consistency
Summary quickly
- Implement data versioning and the
optimistic concurrency control
CAP theorem
- CQRS is about making different choices
with regards to the balance within CAP
- Choose consistency and availability at the
expense of partitioning for writes
- Choose availability and partitioning at the
expense of consistency for reads
 In the Next Module

CQRS Best Practices and

Misconceptions