CQRS is probably the cause of the Microservices madness

Reads and Writes don’t have to live in the same database, data model or even the same service. Let us discuss CQRS

no separation
one service that does read/write

partial separation
You can keep one service but backend have multiple connections with different users same database

full separation
Read services / write services
two databases OLAP / OLTP

Pros
scalability
security

Cons
complex and very hard to follow, what we see with microservices..

resources

🎙️Listen to the Backend Engineering Podcast

🏭 Backend Engineering Videos

💾 Database Engineering Videos

🏰 Load Balancing and Proxies Videos

🏛️ Software Archtiecture Videos

📩 Messaging Systems

Become a Member

Support me on PayPal

Join our Thriving Backend Community on Discord

Stay Awesome,
Hussein

[hnasr]

Videos mentioned in this video

Column vs row oriented database


Microservices explained



Microservices madness

[andrewmartin]

I thought this video would be about Cross Qite Request Sorgery.

[EskoLuontola]

CQRS doesn't require multiple services or processes. All it says is that there are separate interfaces or object models for reads and writes. It all can be in a single process. The interesting part about CQRS is all the other patterns that it enables. The links in the description explain CQRS well, especially the article from Greg Young.

[Tube_user_]

Great subject to be discussed.
In my previous job we found ourselves in a situation where a kind of CQRS seemed the right way to go by using different paths to write and read, but just in the code level, without worrying about separating services in the infrastructure level:
- Write: creating a well defined Entity to write objects to DB
- Read: using complex queries to create very specific Data Structures that the Front-end app needed to build, for example, dashboards and charts

It worked really well, and the code was simplified when compared with Entities manipulation in memory everytime a new specific data structure was needed in front-end.

[francksgenlecroyant]

Whenever I come across a confusing and complex topic, I always look for Hussein on youtube and he explains me everything, thanks Hussein 👊👊👊

[kyroxen]

6:00 "Know that it exists..." I've now subscribed to this policy. Zen. Looking forward to your DDD video!

[mannion]

Great video, interesting topic. A couple of points to add: a main advantage of CQRS is that much more than storing data in a separate place, you can project custom views to your every query requirement, which can be really powerful and useful. We've all written monster queries that join across a dozen tables for some report in the past and CQRS is a means to avoid this. Twitter which is read-heavy with queries for timelines being what they are, it would be impossible without dedicated projections and eventual consistency. At the end you mentioned about writes reading to do reads and running into problems with that - this is usually a symptom of misplaced boundaries rather than a limitation of CQRS itself. Also, CQRS isn't a set of rules to be followed to the letter, with pragmatism you can avoid huge problems there. I completely agree that CQRS adds complexity, doesn't fix every problem, and is a death sentence for any project where it is not the correct tool for the job, we aren't all building Twitter at the end of the day - CQRS is a solution for problems that start to appear at massive scale.

[patricknebe]

Hey man, thanks for all the content you put out on YouTube. I recently used some of your videos to prepare for my Systems Architecture/Design Interview and what I learned from you turned out to be super helpful during my interview. Thanks again and keep up the good work 💪🏼

[MubashirAR]

Lol when I read the thumbnail I thought "Ugh.. another cors like thing again!" 😅

[akashagarwal]

Just wondering if this channel is well appreciated like any other gold mine

[FredrikRambris]

Finally! Someone with some sense not jumping on every bandwagon passing by. Thank you!

[fbsouza]

In my opinion, it's not just about simply reads and writes. It's about commands (which may require a read, call some api, and write), and queries.

[hashimjarral]

Always something new to learn. Thank you, Hussein.

[chessmaster]

The simple reason is RDBMS normalization prevents duplication (PK), Referential Integrity (FK) enforces data consistency and that is high performance for data create(C), update(U), delete (D), For (R) queries. especially complex queries, we need to join multiple normalized tables. So, to improve performance of queries, we would like to create Materialized Views with the requited joins to make that there are no joins on the fly. The joins are defined as part of materialized view definition and indexes live on the materialized view. So, your queries say select * from materialized view where values criteria only with no joins. The materialized views can be refreshed behind the scenes, on commit e.g. so when new data is created, updated, deleted then only materialized view gets refreshed. The materialized view can live on a separate machine and gets refreshed automatically once we define the materialized view. All this sounds very good but it has a lot of performance implications and people avoid this or introduce delayed refresh generally. That is eventual consistency. This may not be acceptable in many cases so people won't do it many times. That is what CQRS is all about and finally says don't do if it does not work for you. it is just a possibility. I just wonder why people won't talk about this. tis is the origin of it. People talk in terms of services CUD & R and never talk about DB part of it.

[jon]

This video was great. As a beginner / mid level backend person, I was struggling navigating through documentation and knowing if this was an absolute must or a bonus thing that you could do to accomplish potential performance gains

[HimanshuPandey]

I have been working with CQRS years before i heard of the term. Sometimes these terminologies are more complex than the actual thing.

[vikas]

Really excited, bcz you said you gonna talk about DDD in next videos. I just started learning it a week ago😁.

[kevinkkirimii]

If I remember correctly microservices is a subset of SOA (Service Oriented Architecture), it took SOA to a granular level by separating services by domain/function. CQRS technique came about through the experience microservice implementations with a large dataset and that is why as you put it very well Folwer said that most implementations won't require CQRS just CRUD.

[shreyasjejurkar]

CQRS is populated with other concepts a lot. At the core, CQRS is just seperating reads and writes! Those might be methods as well and not only objects! Even Greg Young demonstrates this concept with methods only!

[jwbonnett]

I think people miss that it is more about optimisation of reads and writes not really seperation so to speak, e.g. the CQRS pattern has event sourcing in mind, it has no joins in terms of tables or querying, same goes for the reads database with the projections (views) being a single table with all the data that it needs. Also if you need to read before a write, you read from the write database due to it having the most up to date information. The read database is just a cache, the information is already out of date.