CQRS : Introduction

CQRS : IntroductionShah Ali Newaj Topu, CTO, Selise

How do we architect enterprise application

Application Layer (Client)

Service Layer

Business Logic Layer

Data Access Layer

Security

Logging

Relational Database

A typical request LifeCycle

newContactID=ContactService.AddContact(Contact)

return ContactManager.AddContact(Contact);

If(Validate(Contact))return ContactRepository.Add(Contact)

Insert into… return newContactID

Relational Database

What happens on UI

What happens on UI

and we wait

and taken back to the grid

Why we wait?

Because it takes some time to add the information to the Database and return us the newly created ID.

Why database takes time?

● More write operation might be in progress.● Lot of read operation might be in progress.● Some request itself might take longer than

others because it has to update multiple tables.

● And so on.

What happens when we read data

contactList=ContactService.GetContacts()

return ContactManager.GetContact();

return ContactRepository.Get()

Select from ...join…join return contactList

Relational Database

and we wait

and ta da..

We have 2 wait screens

Can we get rid of them?

Why we wait?

● Lots of Joins in Select query● There was some write request from other

users which locked the table we were trying to read.

Why we have Joins

Because we have Normalized Database

And we need Normalized database because

Normalization slows down read operation

The best READ performance can be achieved from a Denormalized Database where data is duplicated and found in columns rather than rows.

Can we have best of both

Imaging you have one service that does all the WRITE operation and updates your Normalized Database and ensures data integrity.Then you have one service that reads the data from a Denormalized Database.And somehow these two Databases are synchronized.

Separation of Read and WritecontactList=ContactREADService.

GetContacts()

return ContactManager.GetContact();

return ContactRepository.Get()

Select * from Contact return contactList

Denormalized Database

newContactID=ContactWRITEService.AddContact(Contact)

return ContactManager.AddContact(Contact);

If(Validate(Contact))return ContactRepository.Add(Contact)

Insert into… return newContactID

Normalized DatabaseSync

We can deploy them separately

More Read Service Less Write Service

But this just a small improvement

We still need the loading screen because Sync will take time and if we make a call to the read service before the sync is done we will not get the data we are looking for.

But lets look back

We have all the data on the ClientWe refresh our grid to show the newly added row by doing a query to the read service.Why?We have all the data in the client because user just now entered it, remember? In the add contact screen. Why we need to query to the read service for data which we already have?

So..

Can we add the row to the grid without making a call to the Read Service?

But we still have to wait for Write

Remember our Write Operation returns an ID. We need this ID to uniquely identify the Data we are writing.What if the Write takes long? We will need a wait for that anyway!

Redefining ID

What if we stop asking the Database to create this id and send it back?What if we generate the ID at the client?What if the ID is a GUID?

Redefining IDContactWRITEService.AddContact

(Contact)

ContactManager.AddContact(Contact);

If(Validate(Contact))ContactRepository.Add(Contact)

Insert into…

Normalized Database

Client becomes independent

For each data change client can now make a call to the write service and without waiting for return value it go back to do the next operation.

Write service can take its time to perform the operation and update the read database accordingly.

Read and Write are independent

Read services only reads dataWrite services only changes the data.

Command Query Responsibility Segregation.

● A Pattern○ Not an Architecture○ Not an Architectural style○ Not a principal

● Based on Command Query Separation Principle

Udi Dahan Greg Young

CQS PrincipalCommand–query separation (CQS) is a principle of imperative computer programming. It was devised by Bertrand Meyer as part of his pioneering work on the Eiffel programming language.

It states that a method should either change the state of an object or return a result but not both.

The Reactive Manifesto

Systems built as Reactive Systems are more flexible, loosely-coupled and scalable. This makes them easier to develop and amenable to change. They are significantly more tolerant of failure and when failure does occur they meet it with elegance rather than disaster. Reactive Systems are highly responsive, giving users effective interactive feedback.

Reactive Systems are

● Responsive● Resilient● Elastic● Message Driven

Necessary patterns

CQRSEvent SourcingDomain Driven DesignEvent Driven Architecture

How does it look

Who is doing it?MicrosoftIn July 2012 Ms started a project called CQRS Journey. The project is focused on building highly scalable, highly available and maintainable applications with the Command & Query Responsibility Segregation and the Event Sourcing patterns. Now they published a book and a fully documented source for implementing CQRS.

Who is doing it?

Java:● AxonFramework● Jdon FrameworkScala:● eventsourced

Who is doing it?

Selise:We are building Publiweb, a massive multi module, multi tenant , SaaS based highly scalable application using CQRS, Event Sourcing and Domain driven design for Swiss E-Gov.

What no one told me

When you are asked to develop a scalable web application you are indeed asked to build a distributed system.

What is a Distributed System

Write Read

What that has to do with Web App

Fallacies of Distributed Computing

● The network is reliable.● Latency is zero.● Bandwidth is infinite.● The network is secure.● Topology doesn't change.● There is one administrator.● Transport cost is zero.● The network is homogeneous.