CQRS

What ?
• CQRS stands for Command and Query
Responsibility Segregation, a pattern that
separates read and update operations for a data
store.
• Implementing CQRS in an application can
maximize its performance, scalability, and
security
• CQRS is one of the important pattern when
querying between microservices.
 Used for..
• use CQRS design pattern in order to avoid
complex queries to get rid of inefficient joins
• we can even use different database
for reading and writing database types like
using no-sql for reading and using relational
database for crud operations
• Commands performs update data, Queries
performs read data
 How isolation happens?
• Commands should be actions with task-based
operations like “add item into shopping cart”
or “checkout order”. So commands can be
handle with message broker systems that
provide to process commands in async way
• Queries is never modify the database. Queries
always return the JSON data with DTO objects
CQRS
CQRS is a natural
progression of Event
Sourcing, dividing the
system into the WRITE
and READ models by
segregating
respectively
commands and
queries as inputs and
linking both models
internally with an
Event Store.
Scenario-1
CONVENTIONAL Read & write model
CQRS-Event driven architecture
• The CQRS pattern is often used along with the
Event Sourcing pattern.
• CQRS-based systems use separate read and
write data models, each tailored to relevant
tasks and often located in physically separate
stores. 
Instagram Database Architecture
 Instagram
• No-Sql Cassandra database for user stories
that is read-incentive data
– if our application is mostly reading use cases and
not writing so much, then it is a read-incentive
application
• relational PostgreSQL database for User
Information bio update
 How to Sync Databases with
CQRS ?
• using Event-Driven Architecture.
• According to Event Driven Architecture, when
something update in write database, it will
publish an update event with using message
broker systems and this will consume by the
read database and sync data according to
latest changes.
 2..
• But this solution creates a consistency issue,
because of async communication with
message brokers, the data would not be
reflected immediately
• This will operates the principle of “eventual
consistency”. The read database eventually
synchronizes with the write database, and it
can be take some time to update read
database in the async process. 
 3..
• When starting your design, you can take read
database from replicas of write database. By
this way we can use different read-only
replicas with applying Materialized view
pattern can significantly increase query
performance.
 e-commerce Architecture with
applying CQRS Pattern
 Ordering microservices databases
• for the write database for relational concerns
when user create or update an order, use
relational write database
• for the read database for querying concerns
when user query order or order history,use
no-sql read database
• use Kafka for syncing these 2 database with
pub/sub Kafka topic exchanges.
 References
• https://medium.com/design-microservices-
architecture-with-patterns/cqrs-design-
pattern-in-microservices-architectures-
5d41e359768c