What and why CQRS
Great Learning for Beginners
--
Let’s Brush up Basic concepts
- CAP Theorem
CAP Theorem is the concept of distributed database system and it can only have 2 of the 3: Consistency, Availability and Partition Tolerance.
Consistency:- It simply states that it should have the latest write (all read see the latest data at the same time).
Availability:- It states that every request should get a response on success/failure.
Partition Tolerance:- It states that the system will run, despite the number of failures by the network between nodes.
System which is partition-tolerant can sustain any number of network failures. it will not result in failure of the entire network.
Synchronous & Asynchronous
Synchronous code can block further execution until it is finished what it’s executing.
Asynchronous code can not block further execution until it is finished what it’s executing.
Famous example of restaurant for Sync and Async:
Asynchronous
You are in a Restaurant, Waiter comes to take your order after order has been placed waiter gives order to chef and chef start preparing food after food has been prepared waiter gives food to you. Meanwhile, no one is allowed to do any kind of moments like waiters can not take orders from other tables, until food is not prepared and not delivered to you. you can not change or add any other items after giving the order to the waiter.
Synchronous
Again, you are in restaurant, Waiter comes to you took your order and gave it to chef and meanwhile chef is preparing food waiter go to other table and take order from them if you ask to do changes in order waiter will write it down and give it to chef and if order can’t be prepared if any ingredient is not there then chef will inform to waiter and waiter will inform to you.
Synchronous code will start from the first line and run until end but Asynchronous code will start from the first line if function calls other function then other function will run like wise till reaches last line.
Start with what is CRUD system all about
CRUD system must be able to perform create, read, update and delete operations. Using CRUD we can construct full and usable models in web applications.
In CRUD you have a current state then something is changed then you have a new state. After a few changes you don’t have any details of the first state.
It will not have Synchronization due to this it will not scale.
In traditional ways we create one model which is updated by UI events and has only one database and corresponding application model. In read and write some model was used despite of working well you can not scale either of read or write.
Event Sourcing before jump into CQRS
Don’t Save current state derive current state.
It has Atomic, immutable events based on this that it derives the current state.
Event Sourcing makes sure all changes to application state are stored in the database as a sequence of events.
Great for testing and statistics
It stores all events which are part of the system.
In the real world we mostly don’t have a consistent system. If you go to a restaurant or shop and ask for your favorite dish. Looks consistent right? But actually, it’s not. Restaurant ingredients may be finished and this leads to inconsistent state.
Consistency can be only possible if we talk with the people with more and more collaborations.
Event Driven Architecture
It is a higher level design paradigm that defines the way parts of your application communicate with each other and can communicate with external applications.
EDA will execute the response to an event and send the notification or action to the right consumers.
Communicate consists of events, event emitters, event managers, and event consumers.
EDA can help you achieve a flexible system that can adapt to changes and make decisions in real time. whether the system is manual or automated, can be made using all of the available data that reflects the current state of your systems.
Events are task or action that took place.
Event Emitters is announce to the application when events take place.
Event managers listen events and inform interested event consumers.
Event consumers subscribe to the event manager and perform some series of actions based on notification of an event.
Example:- Take scenario of Recruitment.
We have three actors 1. employers 2. candidate 3. recruiter
Candidate will send qualification and interest information to the application. Recruiters are constantly monitoring potential employees (candidates) and information broadcasted by them and notify if matches requirement to employers. In this event we get relevant candidates.
Employers are subscribed to recruiters, and they expect to receive notifications when relevant candidates are found. Candidates in the above scenario are event emitters, Recruiters are event managers and employers are event consumers.
Event emitted by candidates are simply a broadcast of qualification, skills and interest. Actions performed by the recruiter consist of parsing the information provided by candidates and determining whether there are any interested consumers to notify. The action performed by employers may be triggering some series of hiring events (Interviews) in a separate system that full-fill hiring process.
CQRS
C_ommand:- Writes
Q_uery:- Reads
R_esponsibility
S_egregation
It Works on so called “One Write Model, N Read Models” often have way more reads than writes; It perfectly fits this scenario as it can have multiple reads or write stores. It basically separating writes from reads and handle events reliably.
It commands either produces events or throws error.
We split Responsibilities and all instances will only communicate via publishing events. All have database systems which can be used to store current states in the system. when the event arrives which will be published from command service.
Then it will go to an event store and then it will be used to update internal representation.
In this system we can scalable any part. If you want to scale either read or write. It also solves event sourcing scale problems. It will give read failover capability for free.
In a CRUD based system if database break down we can not read, can not write but in CQRS based system if the event store is down still you can read because you have all the instances in place that have databases and caches which can at-least return statements.
I liked the hiring process example of medium post and I have mention above https://medium.com/@JustinTRoss/what-is-event-driven-architecture-c2f329b4d89
