You've sat in this meeting. A product with a few thousand paying accounts, one Postgres database that isn't struggling, and a design doc proposing a separate read model, a separate write model, and an event bus to keep them talking to each other. Ask why, and the answer is some version of "this is how it scales." Nobody in the room asks scales to what, or from what number to what number. That's CQRS (Command Query Responsibility Segregation) walking through the door, not because the system has a problem it solves, but because someone read about it in a system design interview guide and has been waiting for a reason to use it.
CQRS is a real tool. It solves real problems at real companies. It also gets adopted, constantly, by teams that don't have those problems, because it photographs well in an architecture diagram and reads well on a resume. The pattern itself isn't the issue. The issue is that almost nobody stops to check whether their system actually has the mismatch CQRS is designed to fix before they build it.
What CQRS Actually Is, Stripped of the Hype
CQRS (Command Query Responsibility Segregation) means you stop using one model to both write your data and read it back. Commands go through a model shaped for validation and business rules. Queries go through a separate model, often a separate store, shaped for however the UI or report actually needs the data. That's the whole idea. No event sourcing required, no message bus required, though people bolt those on constantly and then call the bundle "CQRS" as if it's one thing.
Here's what nobody tells you in the diagram: the moment you split the model, you've taken on a synchronization problem. Your write side and your read side now have to agree with each other, and if they're not in the same transaction, they will occasionally disagree. That's not a bug you introduced by accident. That's the deal you signed up for. The question worth asking, every time, is whether the deal was worth it.
The Interview-Prep Pipeline That's Selling You This Pattern
Go look at where most engineers first meet CQRS. It's not a postmortem. It's a system design interview guide, sitting next to sharding and consistent hashing, presented as a thing senior engineers are supposed to know and use. Then it shows up again in a "how Netflix does it" or "how Uber does it" blog post, describing a system handling millions of events a second across a global user base.
Neither of those sources is lying. CQRS earns its keep at that scale. The problem is what happens next: an engineer who just studied that material joins a team building an internal tool, or a B2B SaaS product with a few thousand paying accounts, and reaches for the same pattern because it's fresh in their head and it looks like the mark of someone who thinks about architecture seriously. The team doesn't have Netflix's read/write ratio. It doesn't have Uber's domain complexity. It has a CRUD app with a dashboard.
This is resume-driven architecture, and it's worth naming plainly instead of dancing around it. Adopting a pattern because it will look good in your next interview, or because implementing it feels more like "real engineering" than shipping CRUD endpoints, is a real and common motivation. It's just not a technical reason, and the codebase doesn't care how the decision felt at the time.
When the Read/Write Mismatch Is Actually Real
CQRS is a legitimate answer to a specific, measurable problem: your read load and your write load want to scale differently, on different hardware, at different rates. A social feed is the canonical case. Writes are a trickle: one post, one like, one comment at a time. Reads are a flood: every user's feed gets recomputed or fetched constantly, fanning out across followers, filters, and rankings. Trying to serve both from one schema on one database means you're constantly compromising one side to protect the other.
If you can point to actual numbers, request logs, database load graphs, a query pattern that's degrading write performance, then you have a real case. If your justification is "reads and writes will probably diverge as we grow," you don't have a case. You have a guess, and CRUD with good indexes and a read replica will absorb most guesses just fine.
When the Domain Genuinely Needs Two Shapes
The other legitimate trigger has nothing to do with load and everything to do with shape. Some domains have a write model that looks nothing like the queries the business needs. A trading system takes in atomic commands (place order, cancel order, execute trade) and needs to answer questions like "show me this account's realized gains by asset class over the last quarter, adjusted for corporate actions." Forcing that reporting need through the same normalized tables you use for order placement means either a write model bloated with reporting concerns, or queries so gnarly they become the thing nobody wants to touch.
That's a domain complexity argument, and it's separate from the load argument. You can have one without the other. A low-traffic system with a genuinely awkward domain can justify CQRS on shape alone. A high-traffic CRUD app with a simple domain usually can't, no matter how much load it takes, because scaling reads and writes at different rates doesn't require different models, just different infrastructure in front of the same one.
Eventual Consistency Is a Business Call, Not a Technical One
Every CQRS implementation that separates the write store from the read store is making a bet that a delay between "the write happened" and "the read reflects it" is acceptable. Sometimes that delay is milliseconds. Sometimes, under load or with a queue backup, it's longer than anyone modeled for.
This is not something engineering gets to decide alone. If a customer submits a refund and then immediately checks their account balance and sees the old number, is that a bug report or an accepted tradeoff? If a warehouse manager updates inventory and a sale goes through against stale stock ten seconds later, who eats that cost? These are product and business questions, and they need an actual answer from someone with the authority to give one, before the architecture is chosen. If nobody on the business side has ever been asked "is eventual consistency fine here," treat that as a sign the decision was made in a vacuum.
The Bill You Don't See Until Month Three
The interview-prep version of CQRS skips the maintenance cost, because interviews don't ask you to run the thing for a year. In production, splitting your model means:
You now debug two systems instead of one whenever the read side shows something that doesn't match the write side. That class of bug is uniquely painful because both sides individually look correct. The projector or sync job that keeps them aligned is new code, with its own failure modes, that didn't exist in the single-model version. Schema changes now happen twice, once for the command side and once for the query side, and someone has to remember to update both, in the right order, without downtime.
None of that is disqualifying if the mismatch you're solving is real. All of it is dead weight, paid every sprint, if you adopted the pattern because it looked right rather than because it was needed. A CRUD app that added CQRS for resume value now has two things to keep in sync forever, in exchange for a problem it never had.
A Test Before You Reach for CQRS
Before you split the model, write down, specifically, what breaks today without it. Not what might break at ten times your current traffic. Not what a blog post said breaks at someone else's scale. What breaks in your system, this quarter, with your actual numbers. If you can point to a load graph or a query that's genuinely fighting your writes for resources, or a domain where the write shape and the read shape have diverged so far that one query is a five-hundred-line stored procedure nobody understands, you have a case. Write that case down and get someone with product authority to sign off on the consistency tradeoff before you build anything.
If what you have instead is a hunch that CQRS is what "real" systems do, or an interview coming up where you want to say you've implemented it, don't build it into your production system to find out. Build a toy project. Your team's CRUD app doesn't need to carry that cost so you can rehearse an answer.
CQRS is a legitimate tool for a narrow set of problems: genuine read/write load divergence, or a domain whose query shape has truly outgrown its write shape, or both. Outside of that, it's not architecture. It's a complexity bet placed with someone else's operational budget, and most teams that place it never had a hand worth betting on.
