Pattern Scope Discipline

CQRS and event sourcing are both correct answers to real problems and both are routinely applied at the wrong scope. Applied to one read path or one aggregate, they solve something. Applied to a product, they impose their costs on every part of it, including the parts that never had the problem.

The rule: the pattern belongs to the use case that justifies it.

Why it matters

The costs are permanent and they are paid everywhere the pattern is applied. CQRS brings eventual consistency between writing and reading your own data, projection code, rebuild paths and lag monitoring. Event sourcing brings immutable schema evolution, upcasting old events forever, an unfamiliar model for every joiner, and a direct conflict with erasure obligations.

Applying them uniformly is how teams end up with projection lag on the one screen where consistency mattered.

Implementation patterns

• Choose per aggregate or per read path, explicitly, with the justification written down.
• For CQRS, require a concrete case: name the slow read, show its current query, and describe the projection. A team that answers with a description of the pattern is proposing a pattern rather than solving a problem.
• For event sourcing, require that the event genuinely is the business record — a ledger, where "deposited" and "bought" are the facts and the balance is a derived opinion. Where it is true, this is an accurate model of the domain rather than a pattern; double-entry bookkeeping has worked this way for centuries.
• Prefer the cheaper approximation first. A materialised view or a well-indexed query answers most read-shape problems; a replica answers most volume-asymmetry problems. Both are an order of magnitude less machinery.
• For audit requirements, distinguish "who changed what and when" from "reconstruct any past state." The first is satisfied by an append-only audit table beside a normal mutable model, at a fraction of the cost.

Industry example

A brokerage such as Groww has a genuine event-sourcing case in the account ledger: the events are the regulatory record, temporal queries like "what was this portfolio worth at 3pm during the circuit breaker" are a real support and compliance question, and corrections are posted as reversing entries rather than applied as overwrites.

The same platform has no case for event-sourcing notification preferences, and a team that applies it uniformly will find itself rebuilding projections to change a display name.

Consumer fintech products such as CRED have the mirror case for CQRS: a personalised feed or rewards summary is an excellent candidate — read-heavy, latency-sensitive, structurally unlike the write model, tolerant of seconds of lag. An account balance is a poor one, because users notice immediately and expect absolute correctness.

Failure scenarios

• Pattern applied product-wide, imposing its costs on parts that never had the problem.
• Event sourcing chosen for sophistication, which is among the least reversible mistakes available: once events are the record, migrating back means reconstructing state and losing history.
• CQRS adopted for volume asymmetry, which replicas solve.
• Projection rebuild never rehearsed, so a projection bug becomes an extended outage.
• Erasure obligations discovered after the event log became the record.

Trade-offs

Scoping a pattern narrowly means the system has more than one shape, and internal inconsistency has a real cost: engineers must know which part follows which model, and code cannot be moved freely between them.

That cost is smaller than the alternative. A system with one heavyweight model everywhere is uniformly expensive; a system with a heavyweight model where it is needed is expensive only there — and the boundary between them, if it is drawn along a domain boundary rather than arbitrarily, is one engineers can hold in their heads.

Interview question

"Your team proposes event sourcing for the whole platform. Where would you agree, where would you refuse, and how would you explain the refusal to someone who has just read a very good book about it?"