Today, i came across a video on ByteMonk on Event Sourcing. In that video, they mentioned about CQRS, then i delved into that. This blog is on understanding CQRS from a high level. I am planning to dive deep into Event Driven Architecture conceptually in upcoming weekend.

In this blog, i jot down notes for basic understanding of CQRS.

In the world of software development, there are countless patterns and practices aimed at solving specific problems. One such pattern is CQRS, short for Command Query Responsibility Segregation. While it might sound complex (it did for me), the idea is quite straightforward when broken down into simple terms.

What is CQRS?

Imagine you run a small bookstore. Customers interact with your store in two main ways

1. They buy books.
2. They ask for information about books.

These two activities buying (command) and asking (querying) are fundamentally different. Buying a book changes something in your store (your inventory decreases), whereas asking for information doesn’t change anything; it just retrieves details.

CQRS applies the same principle to software. It separates the operations that change data (called commands) from those that read data (called queries). This separation brings clarity and efficiency (not sure yet )

In simpler terms,

• Commands are actions like “Add this book to the inventory” or “Update the price of this book.” These modify the state of your system.

• Queries are questions like “How many books are in stock?” or “What’s the price of this book?” These fetch data but don’t alter it.

By keeping these two types of operations separate, you make your system easier to manage and scale.

Why Should You Care About CQRS?

Let’s revisit our bookstore analogy. Imagine if every time someone asked for information about a book, your staff had to dig through boxes in the storage room. It would be slow and inefficient!

Instead, you might keep a catalog at the front desk that’s easy to browse.

In software, this means that,

• Better Performance: By separating commands and queries, you can optimize them individually. For instance, you can have a simple, fast database for queries and a robust, detailed database for commands.

• Simpler Code: Each part of your system does one thing, making it easier to understand and maintain.

• Flexibility: You can scale the command and query sides independently. If you get a lot of read requests but fewer writes, you can optimize the query side without touching the command side.

CQRS in Action

Let’s say you’re building an app for managing a library. Here’s how CQRS might look,

• Command: A librarian adds a new book to the catalog or updates the details of an existing book.

• Query: A user searches for books by title or checks the availability of a specific book.

The app could use one database to handle commands (storing all the book details and history) and another optimized database to handle queries (focused on quickly retrieving book information).

Does CQRS Always Make Sense?

As of now, its making items complicated for small applications. As usual every pattern is devised for their niche problems. Single Bolt can go through all Nuts.

In upcoming blogs, let’s learn more on CQRS.