CQRS: Denormalization, Event Sourcing & When to Use It

Intentional Denormalization on the Read Side

A read model can duplicate data (storing a customer's name directly on an order record) specifically to avoid a join at read time -- data integrity is the write side's concern, and the read model is rebuilt/kept in sync from the source of truth.

Async Sync via Events & Eventual Consistency

// After a write succeeds, publish an event -- a separate process
// consumes it and updates the read model asynchronously
await eventBus.publish('OrderPlaced', { orderId, customerId, items })

// A brief window exists where the write succeeded but the read
// model hasn't caught up yet -- "eventual" not immediate consistency,
// a tradeoff to consciously accept if using this async approach

CQRS vs. Event Sourcing

Distinct, complementary patterns often used together -- Event Sourcing (storing state as a sequence of events) naturally provides the stream a CQRS read model can build from. CQRS works without Event Sourcing; Event Sourcing works without full CQRS.

Polyglot Persistence

Write side: PostgreSQL for transactional integrity when adding/updating products. Read side: Elasticsearch, synced from write-side events, for fast full-text product search. CQRS's separation makes this 'right tool for the job' flexibility practical.

When (Not) to Adopt CQRS

• Genuine added complexity: more code, more infrastructure, a sync mechanism to build and maintain.

• Best justified by an actual measured problem (real query performance strain under real load), not adopted speculatively for traffic that hasn't materialized.

• Apply selectively -- a high-traffic catalog might benefit while a low-traffic admin settings page doesn't need the added complexity.

• A lighter-weight variant (separate command/query code paths, same underlying database) captures some benefit without full physical read/write separation.

• Independent scaling: a read-heavy feed can scale read infrastructure heavily while keeping write infrastructure modest.