Separating What You Say From What You Ask with CQRS
Last month, our team hit a breaking point with our monolithic application. Performance was tanking, and adding new features meant navigating a maze of increasingly complex code.
In this issue, I'll take you through how we tackled this using CQRS (Command Query Responsibility Segregation). No theory dumps – just real code, real problems, and real solutions.
🚀 What you'll learn:
Why separating reads and writes transforms application architecture
How to implement read models in Rails without overcomplicating things
Techniques for dealing with eventual consistency challenges
Practical steps to refactor existing code toward CQRS
The Problem
Our application was struggling under the weight of a growing user base and increasingly complex business logic.
Every new feature required touching multiple parts of the codebase, and our queries were becoming slow and unwieldy.
Here's what we were dealing with:
💡 Warning Signs:
Controllers handling both complex reads and writes
ActiveRecord models bloated with business logic
Slow page loads due to complex joins and calculations
Difficulty adding new views without breaking existing ones
Testing becoming increasingly difficult
From Problem to Solution
Step 1: Separate Commands and Queries
Before:
After:
🎯 Impact:
Each class has a single responsibility
Testing becomes more straightforward
Changes to one operation don't affect the other
Easier to understand what each component does
Step 2: Implement Dedicated Read Models
Before:
After:
The Aha Moment
Our breakthrough came when we realized we didn't need to completely overhaul our app at once. We could apply CQRS principles incrementally, starting with the most problematic areas. This allowed us to make progress without being paralyzed by a massive refactoring project.
Real Numbers From This Experience
Before: 850ms average response time
After: 320ms average response time
Database queries reduced by 60%
Server load reduced by 45%
The Final Result
🎉 Key Improvements:
Clean separation of concerns
Improved performance through optimized read models
Easier to scale read operations independently
Simpler testing with focused components
Clearer understanding of application flow
Monday Morning Action Items
1. Quick Wins (5-Minute Changes)
Identify your most complex controller actions
Create a list of read vs. write operations in your app
Start documenting which models are used for reading vs. writing
2. Next Steps
Extract a simple read model for your most-viewed page
Create a dedicated command object for one complex write operation
Set up background jobs to update read models asynchronously
Your Turn!
The CQRS Challenge
Take a look at this controller action and consider how you might refactor it using CQRS principles:
💬 Discussion Prompts:
What problems do you see with mixing reads and writes in this action?
How would you separate the read and write responsibilities?
What read model(s) might you create to optimize this page?
What's Next?
Next week: "Event Sourcing with Rails" - Discover how to track every change in your system for perfect auditability and new capabilities.
🔧 Useful Resources:
Found this useful? Share it with a fellow developer! And don't forget to reply with your own CQRS experiences or questions.
Happy coding!
Pro Tip: Start with read models first - they're easier to implement and provide immediate performance benefits
Remember: CQRS doesn't mean you need separate databases - start simple!