You're designing a new cloud service and a colleague proposes building it with CQRS and full event sourcing from day one because 'it's the scalable, cloud-native way to do it.' When would you push back on that default?

## Not a free upgrade CQRS with event sourcing is a powerful pattern, but it is not a free upgrade — it trades simplicity for capabilities that a given service may or may not actually need: - independent read/write scaling; - multiple denormalized views; - full auditable history; - temporal queries. As a senior engineer, the right response to 'let's do CQRS+ES because it's cloud-native and scalable' is to ask what specific problem it's solving here, because in a meaningful fraction of cases the honest answer is 'none yet,' and adopting it anyway is taking on real cost for hypothetical future benefit. ## Scale that isn't there yet The first case to push back on is scale that doesn't exist. CQRS earns its complexity when read and write load genuinely diverge enough that scaling them together is wasteful, or when multiple consumers need meaningfully different denormalized views of the same data. A brand-new service, an internal tool, or anything pre-product-market-fit typically doesn't have that asymmetry yet — traffic is low, the data shape is still changing, and a single well-indexed relational database easily handles both reads and writes with room to spare. Building the two-model, event-log, projector-pipeline machinery for that workload means paying operational cost for scaling headroom nobody is using. ## A strict consistency requirement The second case is a strict consistency requirement that fights the pattern's core tradeoff. Event sourcing with asynchronous projections is fundamentally eventually consistent between write and read sides. Domains where a read must reflect the absolute latest write with no exceptions — for example, checking an account has sufficient balance immediately before authorizing a debit, where stale data could allow an overdraft — either need read-your-writes machinery (added complexity again) or are simply a poor fit, and are often better served by a single, strongly-consistent transactional store for that specific check, even if other parts of the same system do benefit from CQRS. ## Team and organizational readiness The third case is team and organizational readiness. Running an event-sourced write model and a projection pipeline is an ongoing operational commitment: - someone owns event schema evolution and versioning as the domain model changes over time; - someone monitors and responds to projector lag and poison-pill events; - someone owns the replay/rebuild runbook for when a projection needs reconstructing. A small team without experience operating this kind of pipeline, or without the on-call maturity to notice and fix a stuck projector, will feel this cost immediately and constantly, often more than the scaling benefit is worth at their current size. ## A domain with no history or audit need The fourth case is a domain without a genuine history/audit need. One of event sourcing's real, distinct benefits — beyond CQRS itself — is a complete, immutable history of every state change, useful for audit trails, debugging 'how did we get into this state,' and temporal queries. If a domain has no such requirement and the CRUD-style 'current state only' model is genuinely sufficient, event sourcing's append-only, replay-based mechanics add cost without buying anything the team will use. ## The pragmatic default None of this means CQRS+ES is a bad pattern — it means it's a pattern with a real activation cost that should be justified by a real need, not adopted preemptively as an assumed best practice. A pragmatic default for a new cloud service is to start with a straightforward single-model CRUD design, keep write-side logic reasonably well-isolated so a later migration isn't a full rewrite, and introduce CQRS — and, separately, event sourcing, since they're independent decisions that are often bundled together but don't have to be — once a concrete, observed need shows up: - read load that's meaningfully outpacing writes; - a genuine need for several differently-shaped read views; - a compliance mandate for full auditability. ## Where it shows up A concrete real-world shape of this judgment call: a startup's early billing service starts as a conventional CRUD service on a single relational database. Only after it grows into a platform serving multiple downstream consumers — a customer-facing invoice view, an internal reconciliation dashboard, and a compliance audit requirement — does the team introduce event sourcing for the ledger (for the audit trail) and CQRS projections for the now-genuinely-different read views, rather than having built that machinery speculatively on day one when none of those needs yet existed.