Combining CQRS with Event Sourcing for Auditable Data Pipelines

Traditional application architectures often rely on a single data model that serves both data entry and data retrieval. While this approach works well for simple CRUD operations, it creates significant friction as systems grow in complexity. High-performance applications frequently require data to be presented in shapes that differ drastically from how that data is most efficiently stored.

The Command Query Responsibility Segregation pattern addresses this friction by splitting the application into two distinct paths. Commands handle actions that change state while queries handle requests that read data. By treating these operations as separate concerns, developers can optimize the write path for consistency and the read path for speed and flexibility.

Moving toward a segregated model shifts the mental burden away from complex relational joins and toward a stream-oriented mindset. Instead of forcing a single database schema to satisfy every user interface requirement, you can create specialized read models tailored to specific views. This decoupling allows the system to scale its read and write components independently based on actual traffic patterns.

The primary benefit of CQRS is not just performance but the reduction of cognitive load when dealing with complex business logic that differs from data display requirements.

Event Sourcing often serves as the ideal foundation for CQRS by capturing every change as a discrete immutable event. Rather than overwriting a row in a table to reflect the current state, the system appends a new event to a sequential log. This log becomes the definitive source of truth from which any current or past state can be derived.

Each event in the stream represents a business fact that has already occurred, such as an item added to a cart or a shipping address updated. Because these events are immutable, they provide a reliable foundation for building downstream projections. The stream acts as a bridge between the command side where logic happens and the query side where data is consumed.

1interface DomainEvent {
2  readonly aggregateId: string;
3  readonly version: number;
4  readonly occurredAt: Date;
5}
6
7class OrderPlaced implements DomainEvent {
8  constructor(
9    public readonly aggregateId: string,
10    public readonly customerId: string,
11    public readonly items: Array<{ sku: string; quantity: number }>,
12    public readonly version: number,
13    public readonly occurredAt: Date = new Date()
14  ) {}
15}
16
17class OrderCancelled implements DomainEvent {
18  constructor(
19    public readonly aggregateId: string,
20    public readonly reason: string,
21    public readonly version: number,
22    public readonly occurredAt: Date = new Date()
23  ) {}
24}

The example above demonstrates how events capture the intent and context of a change rather than just the final values. By storing the reason for a cancellation or the specific items in an order, we preserve data that a traditional update-in-place model would lose. This granular history is invaluable for debugging, auditing, and future business analysis.

Read projections are specialized data structures that transform raw event streams into formats optimized for specific queries. A projection worker listens to the event stream and updates a secondary database, such as a document store or a cache, in real time. This allows the application to serve complex queries with simple lookups, bypassing the need for expensive runtime calculations.

Because projections are derived from the event stream, they can be discarded and rebuilt at any time. If the business needs a new way to visualize data, you do not need to perform a risky migration on your primary database. Instead, you create a new projection, replay the historical events from the start of the stream, and populate the new table.

• Projections allow for radical schema flexibility without downtime on the write side.
• Different projections can use different storage technologies like Elasticsearch for search or Redis for real-time dashboards.
• Historical replays enable retroactive bug fixes by correcting projection logic and reprocessing past events.
• Read models can be scaled out horizontally across multiple regions to reduce latency for global users.

1// A projection handler updates a dedicated read-model database
2async function handleOrderEvent(event, db) {
3  switch (event.type) {
4    case 'OrderPlaced':
5      // Increment total sales count and update customer spending
6      await db.collection('customer_stats').updateOne(
7        { customerId: event.customerId },
8        { $inc: { totalOrders: 1, totalSpent: event.amount } },
9        { upsert: true }
10      );
11      break;
12    case 'OrderCancelled':
13      // Adjust stats for the cancellation
14      await db.collection('customer_stats').updateOne(
15        { customerId: event.customerId },
16        { $inc: { totalOrders: -1, totalSpent: -event.amount } }
17      );
18      break;
19  }
20}

The ability to replay events is a transformative capability for long-lived software systems. In traditional systems, once data is deleted or transformed during a migration, the original state is lost forever. With an event-sourced CQRS setup, the entire history of the system is preserved, allowing you to answer questions you had not even thought of when the system was built.

When a bug is discovered in how a certain metric is calculated, you simply fix the code in the projection worker. After the fix is deployed, you reset the projection and replay the event stream from the beginning of time. The system will process every historical event again, resulting in a perfectly accurate and corrected read model without any manual data patching.

This replayability also supports experimental features and blue-green deployments for data. You can run two versions of a projection side-by-side to verify that a new implementation produces the expected results before switching traffic. This reduces the risk of deploying complex analytical changes and gives the engineering team greater confidence in their data integrity.