// 19 - The Event Sourcing, Materialized View and CQRS Patterns

These three cloud design patterns — Event Sourcing, Materialized View, and CQRS — are frequently used together in event-driven systems and are especially well-suited to cloud environments like Azure. In this episode, Chris and Steph explore each pattern individually and explain how they complement each other.

Event Sourcing

Instead of storing only the current state of an entity, Event Sourcing records every event that led to that state as an immutable, append-only log. Think of it as a complete audit trail of decisions:

• A customer adds an item to their basket → event recorded
• They remove an item → event recorded
• They complete the purchase → event recorded

This history enables rich analytics, targeted personalisation, and the ability to reconstruct state at any point in time. Azure Cosmos DB’s change feed is a natural fit for implementing this pattern at scale.

Materialized View

Raw event logs are powerful, but querying them directly can be expensive. The Materialized View pattern pre-computes a denormalised, query-ready view of data from one or more event streams. This is particularly valuable when the source data structure doesn’t match the shape required by consumers — a common challenge in microservices architectures.

CQRS (Command Query Responsibility Segregation)

CQRS formally separates the write model (commands that change state) from the read model (queries that return data). This separation allows each side to be independently scaled and optimised. Event Sourcing and Materialized Views map naturally onto the CQRS model: events flow from the command side, and materialized views serve the query side.

When to Use These Patterns

These patterns add architectural complexity and are best suited to domains where audit history, temporal queries, or significant read/write asymmetry are genuine requirements — not as a default choice for every application.