# What is CQRS?

**CQRS** stands for **Command Query Responsibility Segregation**. The idea is simple: **Separate the part of your system that changes data from the part that reads it.**

Traditionally, most applications use a single model or service to handle both reading and writing – typically in the form of **CRUD** (Create, Read, Update, Delete). With CQRS, you break this pattern in favor of **clear responsibilities**:

- **Commands** change state.

    They represent actions, such as **"BorrowBook"** or **"ExtendLoan"**.

- **Queries** read state.

    They return data, but **never modify anything**.

This distinction isn't just about code structure – it's about **reflecting intent**.

## Why Separate Commands and Queries?

In the real world, **reading and writing follow different rules**:

- **Reads** are frequent, fast, and optimized for display.
- **Writes** are often more complex: they trigger **business logic**, **validations**, and **workflows**.

By separating them, you can **optimize each side independently**:

- **Read models** can be designed for **fast UI access**.
- **Write models** can focus on **enforcing rules** and expressing **domain logic**.

## CQRS is About Behavior, Not Storage

CQRS does **not** require multiple databases or any particular infrastructure. It’s a **design principle** that helps you model your system in a way that matches the **mental model of your users**.

When you think in terms of **commands** (*"What is the user trying to do?"*) and **queries** (*"What does the user need to know?"*), your system becomes **easier to reason about** – and better **aligned with the real world**.

**Ready to go further?** Next, learn about **[Event Sourcing](/concepts/event-sourcing)** – a natural fit for systems built on CQRS.