Event Sourcing isn't about storing the current state of an application, but rather the sequence of events that led to that state. Instead of updating a row in a database (e.g., SET balance = new_balance), you persist an immutable event record like MoneyDeposited(accountId, amount, timestamp). The application's current state is then derived by replaying these events in order. This provides an unparalleled audit log, allows for "time travel" (reconstructing state at any past point), and makes temporal queries straightforward. It forms the backbone of highly reliable and auditable systems, naturally integrating with event-driven architectures where these events are also published for other services to consume.
CQRS, or Command Query Responsibility Segregation, is a pattern that separates the concerns of modifying data (commands) from reading data (queries). Traditionally, a single data model and database schema serve both. With CQRS, you'll have distinct "write models" designed for handling commands and "read models" optimized for specific query needs. For instance, your write model might be a rich domain model focused on business rules, while your read models could be highly denormalized PostgreSQL tables, Elasticsearch indices, or even materialized views tailored for specific UI displays or reporting requirements. This separation allows independent scaling, optimization, and evolution of read and write sides.
When combined, Event Sourcing and CQRS create a powerful, robust architecture. Commands flow into the write model, which validates business rules and then emits events (Event Sourcing). These events are persisted as the system's single source of truth and then asynchronously processed to update one or more read models (CQRS). This loose coupling means read models can be eventually consistent, tailored for performance, and even discarded and rebuilt from the event store if requirements change. While introducing complexity like eventual consistency and managing event schema evolution, the benefits in terms of auditability, scalability, and flexibility for complex domains often outweigh the trade-offs for advanced backend systems.
Key Takeaways
- Event Sourcing: Store every state-changing action as an immutable event; derive current state by replaying events.
- CQRS: Separate data models for commands (writes) and queries (reads) to optimize each responsibility.
- Synergy: Commands generate events (ES); events update highly optimized, often denormalized, read models (CQRS).
- Benefits: Enhanced auditability, temporal querying, improved read scalability, and flexible query performance.
- Trade-offs: Introduces eventual consistency and increased architectural complexity.
Code Example
class AccountCreated:
def __init__(self, account_id, initial_balance):
self.account_id = account_id
self.initial_balance = initial_balance
class MoneyDeposited:
def __init__(self, account_id, amount):
self.account_id = account_id
self.amount = amount
event_store = []
def create_account(account_id, initial_balance): event_store.append(AccountCreated(account_id, initial_balance))
def deposit_money(account_id, amount): event_store.append(MoneyDeposited(account_id, amount))
current_balances_read_model = {}
def apply_event_to_read_model(event):
if isinstance(event, AccountCreated):
current_balances_read_model[event.account_id] = event.initial_balance
elif isinstance(event, MoneyDeposited):
current_balances_read_model[event.account_id] += event.amount
create_account("acc123", 100)
deposit_money("acc123", 50)
for event in event_store:
apply_event_to_read_model(event)
# Query the read model (e.g., current_balances_read_model["acc123"] would be 150)How this code works
This code demonstrates fundamental concepts of Event Sourcing and CQRS by managing bank account balances through a sequence of events. Instead of directly modifying account balances, every change is recorded as an immutable event. The system then rebuilds a query-optimized view from these events. AccountCreated and MoneyDeposited are simple event classes, representing facts that have occurred. When commands like create_account or deposit_money are invoked, they don't alter application state directly. Instead, they append new events to the event_store, which serves as the definitive, ordered log of everything that has ever happened in the system.
The current_balances_read_model is a separate data structure designed for efficient querying, detached from the event store. The apply_event_to_read_model function defines how each event type modifies this read model's state, for example, setting an initial_balance or adding an amount. A key insight is the final for loop: it rebuilds the entire current_balances_read_model by replaying all events from the event_store from the beginning. A subtle point for beginners is that the current_balances_read_model isn't updated by create_account or deposit_money directly; it's updated only by processing replayed events, ensuring the event_store remains the single source of truth.