Event Sourcing 101: Command Query Responsibility Segregation (CQRS)

cnfl.io/event-sourcing-101-mo... | CQRS (Command Query Responsibility Segregation) provides a solution for the delays that can accompany large chronological reductions in event-based systems. It accomplishes this by segregating systems into a write side and read side. Operations, such as reduces, are performed asynchronously on your events when they are written, as opposed to when they are queried for reads. This extensively reduces the latency of your queries.
Use the promo code EVENTS101 to get $25 of free Confluent Cloud usage: www.confluent.io/confluent-cl...
Promo code details: www.confluent.io/confluent-cl...
LEARN MORE
► Event-Driven Architecture - Common Mistakes and Valuable Lessons ft. Simon Aubury: developer.confluent.io/podcas...
► "Commander: Better Distributed Applications through CQRS and Event Sourcing" by Bobby Calderwood: • "Commander: Better Dis...
► CQRS: martinfowler.com/bliki/CQRS.html
ABOUT CONFLUENT
Confluent is pioneering a fundamentally new category of data infrastructure focused on data in motion. Confluent’s cloud-native offering is the foundational platform for data in motion - designed to be the intelligent connective tissue enabling real-time data, from multiple sources, to constantly stream across the organization. With Confluent, organizations can meet the new business imperative of delivering rich, digital front-end customer experiences and transitioning to sophisticated, real-time, software-driven backend operations. To learn more, please visit www.confluent.io.
#eventdrivenarchitecture #apachekafka #kafka #confluent

[@alps44]

The most clear explanations on CQRS & event sourcing I've ever watched/read, thank you!

[@puterich]

Short and clear! Very good

[@Akhbash]

CQRS doesn't mean having 2 databases or models, read & write or to compute the Read Model when manipulating Write Model. The definition of CQRS is a term coined by Greg young, to explain an Architectural Pattern that allows for a SoC between a Read Model and a Write Model, the later used for Commands (Create, Update, Delete) and the other for Queries (Read), though not strictly meant only for CRUD. Also, CQRS does not enforce having 2 models.

[@ConfluentDevXTeam]

Hello, Wade from Confluent here. You are correct. CQRS does not require two databases. It also doesn't require asynchronous updates, event sourcing, or a variety of other things often associated with it. Greg Young explains that at its core, CQRS is very simple just separating the two concerns for read and write. Having said that, commonly, CQRS is implemented with all of these other things. It is often used as a solution for Event Sourcing where your write model is Events and then you have read models populated by an asynchronous update, often in a separate database. Think of what Anna is describing here as CQRS specifically in the context of a typical event sourcing application. She's not describing all of the nuances of CQRS, but rather focusing on how you can use CQRS to solve some of the challenges you encounter when working with Event Sourcing.

[@Akhbash]

@@ConfluentDevXTeam Wow, didn't thought someone from Confluent would actually reply, that's awesome! I totally got the point of the video, perhaps I missed my chance on making that clear though. Thanks for the reply ;D

[@alexandresantos7966]

Clear and objective explanation. Thank you.

[@david75186]

it is very interesting to understand this paradigm because help us not to create a complexity where do not need

[@sna241]

Amazing lecture. Thank you.

[@soak2094]

Great explanation, thanks

[@thedacian123]

What would happend if i have to change the event format and we have a lot of events gathered in the log?Thank you!

[@vijayjayaram606]

Much needed right now Thank you 🙏

[@chessmaster856]

What is so much hype? We store events as history and only INSERT for better performance. insertion is suitable in normalized tables. Query portion is easier in denormalized format as a single select * form denormalized. The update from normalized -> denormalized happens only 1 time with kafka queues in the background. I don't think there is more to it. Thats how I would explain 1 line

[@jibranjaved6165]

So the system will eventually "inconsistent" as said read will not b possible right after "write", performance or segregation tradeoffs with data inconsistentcy... Apart from this why I would b interested from real world usecase POV that if user first add T shirt then delete T-shirt n add Pants to the cart n add one more Shirt n delete added Pants n added T-shirt again...ok we are writing these events to eventlog just to have record where user started???why I would b interested what was the system state at the time when this user started shopping??? What I want to achieve from that!??

[@giacmoit]

What is the benefit of CQRS?

[@tharun8164]

The primary intention is to decouple the writes and reads. If you want to understand why do we even need to decouple them, then the below example gives some context. Ex: I assume you're familiar with data structures and algorithms. Let's say we receive input as a stream(array) of numbers and we need to address the following questions. Q1) Print the last 5 numbers. (queue) Q2) Print the top K smallest of all numbers. (priority queue) Q3) Print the sum of numbers. To answer the above questions, we build a data structure tailored to address that specific question so as to improve the time complexity. Similarly, cqrs do this at the systems level.

[@iamnoob7593]

@@tharun8164 I get ur point , Its still not clear . As CQRS can lead to data inconsitency and performance issue

[@tharun8164]

@@iamnoob7593 CQRS may lead to data inconsistency with incorrect implementation. Let’s consider a use case of data integration i.e., we want to persist the same data in 2 different databases. For ex, we wanted to use MySql as a source of truth and Elasticsearch to provide full-text search. If we try to persist the data in MySql and Elasticsearch from the application then it’ll lead to a fundamental problem called ‘dual write’. With this issue, data may become inconsistent between MySql and Elasticsearch due to reasons like a race condition, client failure, or any database failure. In order to mitigate this problem we can implement Change Data Capture(CDC) pipeline. This CDC approach tails the MySql log and applies these changes to Elasticsearch. These MySql logs are converted as events and pushed to Event Bus(Kafka). This CDC pipeline ensures that data is consistent between MySql and Elasticsearch. Since there will be latency in processing these CDC events, it leads to Eventual Consistency. 
Regarding the performance, since the database logs are used in creating events it doesn’t have any impact on existing application latencies.

[@iamnoob7593]

@@tharun8164 wow , thats very detailed . Thanks

[@chessmaster856]

Does it work? It is a question nark

[@ConfluentDevXTeam]

Wade here, from Confluent. Assuming you are asking whether CQRS works, the answer is yes, it does. It is a common solution applied in many event-sourcing use cases. For its intended purpose, it works quite well.

[@ITube4RealFun]

The hand gesture is distracting and she talks too fast.

[@bY6U5T4V0]

there's a speed control tool embedded in KZbin that might help you understand her better.