Lecture 217: When and why to use CQRS

In the last lecture we covered the basic principles of CQRS. Now let's dig deeper and figure out how this pattern plays with other architectural choices, and where it actually makes sense to use it.

How CQRS and Saga get along

Remember our beloved Saga from previous lectures? Well, CQRS and Saga are like pizza and pineapple. Or salted caramel. Some will say it's a weird combo, but those who've tried it know it can be tasty!

Let's walk through a concrete example. Imagine you're building a system for an airline:

• Saga handles the whole booking process: from choosing a seat to payment
• CQRS helps keep the system from falling over when thousands of users search for tickets at once

How do they work together?

1. Commands (writes) go through Saga, ensuring consistency across all operations
2. Queries (reads) are handled separately via CQRS, without interfering with the booking process

Where CQRS really shined

Now let's look at real-world cases. And no, I'm not going to talk about Amazon and Netflix again — let's pick examples closer to home.

Imagine a friend worked at a company that built an online reservation system for a restaurant chain. At first everything was fine — a simple CRUD service on Spring Data JPA handled it easily. But then came the "Black Day" — the restaurant launched a promo "All sushi almost free". The system went down in 15 minutes — way too many people tried to book tables at the same time.

How to deal with that? You can introduce CQRS:

• For writes (booking) — Spring Data JPA with PostgreSQL
• For reads (finding available tables) — Spring Cache with Caffeine or Hazelcast in-memory data grid
• As an event broker for syncing — Spring Cloud Stream with Kafka

Result? The system not only survived the next promo, but also became much nicer to develop: each part does exactly what it should.

Where CQRS can backfire

Now let's talk about the sad stuff. I've seen projects where CQRS turned into a Frankenstein monster. Typical mistakes:

1. "Let's split everything!" Developers got so excited about separation that they created separate models for every operation. In the end a simple CRUD turned into a spaceship with a warp drive.
2. "Why bother with consistency?" Some forget that there's always a delay between writing data and its appearance in the read model. If your users see different data on different screens — that's not great.
3. "CQRS will solve all our problems!" Spoiler: no, it won't. CQRS is like hot sauce: great in the right dish, but don't pour it into your morning coffee.

Alternatives to CQRS

Sometimes CQRS is like using a cannon to kill a sparrow. Let's look at alternatives:

1. Caching Often simple caching solves 80% of read-performance problems. And it's much easier to maintain.
2. Materialized views In PostgreSQL you can create materialized views for complex reports. Sometimes that's enough.
3. Vertical scaling Yeah, it's not very trendy. But sometimes it's easier to buy a beefier server than to complicate your architecture.

When you should actually use CQRS

1. You really have different requirements for reads and writes For example, writes must be strictly consistent, while reads need to be as fast as possible.
2. Read and write loads differ significantly Classic example: a social network where a single post gets thousands of views.
3. You're already using Event Sourcing CQRS complements Event Sourcing really well. But we'll talk about that in the next lecture...

Conclusion

CQRS is a powerful tool, but you need to use it carefully. As the team lead says (what team lead? Pretty much any!): "Don't overcomplicate where you can simplify. And don't simplify where complexity is needed."

Next time we'll get practical and build a real CQRS service. Get your IDEs ready!