Event Sourcing and CQRS: Immutable System States

The Problem with CRUD

Standard Create, Read, Update, Delete (CRUD) architectures suffer from a critical flaw for enterprise compliance and auditing: they mutate state destructively. An SQL UPDATE statement obliterates the previous state of the row. If an executive asks, 'What was the exact state of this customer's cart three weeks ago before the price change?', a traditional application simply cannot answer.

Event Sourcing Mechanics

Event Sourcing fundamentally flips data storage. Instead of storing the *current state*, the database stores a relentless, append-only chronological ledger of all *events* that occurred (e.g., CartCreated, ItemAdded, PriceChanged). To discover the current state, the system simply replays the event log from genesis. This guarantees 100% historical accuracy and offers immediate time-travel debugging capabilities.

CQRS: Dividing Responsibilities

Replaying thousands of events strictly for a 'Read' query is painfully slow. This is where Command Query Responsibility Segregation (CQRS) acts as a force multiplier. The system separates the write model (the Event Store) from the read model. As events are appended, asynchronous workers project those events into highly optimized, denormalized Read Data models (like Elasticsearch or Redis), granting sub-millisecond query performance coupled with mathematically perfect auditability.

Event Store Architecture

An event store is fundamentally different from a traditional relational database. Events are strictly append-only and immutable—once written, they can never be modified or deleted. This immutability provides a tamper-proof audit trail that satisfies regulatory requirements in industries like finance, healthcare, and government. The event store's schema is remarkably simple: typically just a stream_id (grouping events by aggregate), event_type, event_data (the serialized payload), and a monotonically increasing sequence number that guarantees ordering within a stream.

Popular event store implementations include EventStoreDB (purpose-built for event sourcing with built-in projections), Apache Kafka (a distributed log that can serve as an event store with appropriate retention policies), and PostgreSQL with append-only tables (leveraging its ACID guarantees and existing operational expertise). The choice depends on scale requirements: Kafka excels at high-throughput scenarios processing millions of events per second, while EventStoreDB provides richer querying capabilities for domain-driven design patterns.

Snapshot Optimization

As event streams grow long, replaying thousands of events to reconstruct current state becomes impractical. Snapshot optimization addresses this by periodically saving the computed aggregate state at a known sequence number. Subsequent state reconstructions need only load the latest snapshot and replay events that occurred after it. A common strategy is to create snapshots every N events (e.g., every 100 events) or when the aggregate is accessed after idle period, balancing storage costs against reconstruction speed.

Handling Schema Evolution

In long-running event-sourced systems, event schemas inevitably change as business requirements evolve. Unlike traditional databases where ALTER TABLE modifies existing data in place, event stores must handle multiple schema versions simultaneously—old events retain their original format forever. The recommended approach is "upcasting": when reading events, a pipeline of version-specific transformers upgrades old event formats to the current schema on-the-fly. This preserves the immutability of the event log while allowing application code to work with a single, current event format.

More complex schema changes—like splitting one event type into two or merging multiple event types—may require "event migration streams" that create new, canonical event streams by transforming and replaying original events through updated business logic. This is the event-sourcing equivalent of a database migration, and it requires the same careful planning, testing, and rollback strategies that teams apply to traditional schema changes.