A marketplace team proposes CQRS because search and browse read patterns differ sharply from the transactional write model. What evidence should be required before accepting the extra synchronisation and projection complexity?

What CQRS actually costs

Before the evidence question, the price must be on the table:

• A projection pipeline that must be built, monitored, and repaired. It will fall behind, it will fail, and it will need replaying.
• A visible staleness window the product must account for, in the UI and in every downstream decision.
• Two models to keep coherent. A schema change on the write side means a projection change, a backfill and a migration.
• A new class of incident: the read model that is silently wrong. This is worse than an outage because it does not alert — the system is up and serving incorrect data.
• Rebuild capability as a hard requirement. If a projection can be corrupted and cannot be rebuilt from source, the read model has become an unreliable system of record.

The evidence that justifies it

1. The read query cannot be served acceptably from the write model, after optimisation. Not "would be nicer" — measured, after indexes, denormalisation and caching have been tried. For marketplace search this evidence is usually genuine: full-text relevance, faceting across many dimensions and geo filtering are not things a normalised transactional schema does well at any index configuration.

2. The read and write workloads have genuinely different scaling requirements, such that scaling them together is materially wasteful — for example reads exceeding writes by several orders of magnitude with completely different capacity curves.

3. The staleness is acceptable to the product, explicitly. Not assumed. Someone who owns the customer experience must agree that a listing edit taking N seconds to appear in search is fine, and the UI must tell the truth about it.

4. A rebuild path exists and has been exercised. The projection can be regenerated from the source of truth within an acceptable window, and someone has actually done it in a drill.

The strong version of the argument for a marketplace

For search specifically, the team is usually already doing CQRS — a search index fed asynchronously from the transactional store is a read model by another name. The proposal is often not "adopt CQRS" but "acknowledge and formalise what already exists": name the freshness SLO, monitor the lag, build the rebuild path, and handle the failure modes deliberately rather than by accident.

That framing changes the decision, because the complexity is already being paid — just without the observability and the rebuild capability that make it safe.

The counter-proposal worth making

If the driver is one expensive query rather than a whole read workload, a materialised view maintained by the database delivers most of the benefit with far less machinery: the database keeps it coherent, there is no separate pipeline, and staleness is bounded by refresh policy. Reach for full CQRS when the read store is a genuinely different technology — a search engine, a graph store, a column store — because that is when no database feature can bridge the gap.

The judgement

CQRS is a good answer to a real problem and a terrible answer to a hypothetical one. The question to ask is not "do reads differ from writes?" — they always do — but "is there a specific read requirement that survives every simpler option, and can we operate a projection safely?"