A consumer fintech team proposes CQRS because their read and write workloads are very different. What evidence should be required before accepting the added synchronisation, projection and operational complexity?

What CQRS actually costs

Separate models mean a synchronisation mechanism, which means eventual consistency between writing and reading your own data — a user who updates something and immediately does not see it. It also means projection code to maintain, a rebuild process for when projections are wrong, monitoring for projection lag, and a second storage system to operate.

None of that is exotic, and all of it is permanent.

The evidence that would justify it

• The read and write models genuinely differ in shape, not just in volume. A feed assembled from a dozen sources with per-user ranking is a different structure from the normalised records that produce it. Volume asymmetry alone is solved by replicas.
• Read scale exceeds what replicas can provide, or the read shape requires denormalisation that would corrupt the write model.
• The write model must stay normalised for correctness — because it enforces invariants about money — while the read model must be flat for latency.
• Eventual consistency is acceptable for the specific reads in question, and someone has confirmed which reads those are.

The evidence that would refute it

"Reads and writes are different" is true of nearly every system and justifies nothing. If the read shape is a join away from the write shape, a materialised view or a well-indexed query is the answer. If the volume is asymmetric, replicas are the answer. Both are an order of magnitude less machinery.

The partial version that is usually right

Apply CQRS to one read path, not to the system. A personalised feed or a rewards summary is an excellent candidate: read-heavy, latency-sensitive, structurally different from the write model, and tolerant of a few seconds of staleness. The account balance is a poor candidate: users notice immediately, and the correctness expectation is absolute.

CQRS is a pattern for a use case, not an architecture for a product. Applying it uniformly is how teams end up with projection lag on the one screen where consistency actually mattered.

The question to ask in review

"Which specific read is slow, what is its current query, and what would the projection look like?" A team that can answer concretely has a real case. A team that answers with a description of the pattern is proposing a pattern rather than solving a problem.