For decades, CRUD has been the default approach to data persistence. Create a record, read it back, update when things change, delete when no longer needed. Simple, intuitive, and battle-tested across countless applications. Yet as enterprise systems grow in complexity and scale, the limitations of storing only current state become increasingly apparent. Enter event sourcing—a fundamentally different approach that captures not just where your data is, but how it got there.
This article explores why organizations are reconsidering traditional CRUD architectures, when event sourcing makes sense, and the practical implications of making the transition.
Understanding CRUD: The Foundation
CRUD represents the four basic operations for persistent storage: Create, Read, Update, and Delete. When a user updates their profile, the system overwrites the existing record. When an order is cancelled, it’s marked as deleted or removed entirely. This state-based approach mirrors how we naturally think about data—as tables with rows that change over time.
The simplicity of CRUD is its greatest strength. Developers immediately understand how to model entities as database tables. ORMs like Hibernate and Entity Framework provide seamless mappings between objects and relational schemas. Decades of tooling, best practices, and collective experience make CRUD the path of least resistance for most applications.
The CRUD Mental Model
In a CRUD system, your database represents truth at this moment. If a user’s email address is jane@example.com, that’s what the record shows. The fact that it used to be jane@oldmail.com is lost unless you’ve explicitly implemented audit logging—a separate concern from your core data model.
This approach works well when current state is all that matters. Employee directories, product catalogs, and configuration settings often fit this pattern. The history of how data arrived at its current state provides limited value, and storing it would be unnecessary overhead.
Event Sourcing: Capturing Change Over Time
Event sourcing inverts the traditional model. Instead of storing current state, it records every change as an immutable event. The current state becomes a derived view—the result of replaying all events that have occurred.
Consider an e-commerce shopping cart. In CRUD, you might have a record: {user_id: 123, items: [{id: 'shirt', quantity: 2}]}. Add another shirt, and you update the quantity to 3. Simple and efficient.
Event sourcing captures a different picture:
1. ItemAddedToCart { user_id: 123, item_id: 'shirt', quantity: 1, timestamp: ... }
2. ItemAddedToCart { user_id: 123, item_id: 'shirt', quantity: 1, timestamp: ... }
3. ItemAddedToCart { user_id: 123, item_id: 'shirt', quantity: 1, timestamp: ... }
To determine current state, you replay these events. Three “ItemAdded” events means three shirts in the cart. This seems more complex at first glance—and it is. But that complexity buys you capabilities that CRUD systems struggle to achieve.
The Append-Only Log
Event stores are append-only. You can create new events and read existing ones, but you never update or delete them. This immutability provides powerful guarantees. Once an event exists, it represents an unchangeable fact: this action occurred at this moment.
This constraint eliminates entire categories of bugs. No lost updates from race conditions. No confusion about what changed when. No accidental data loss from overwrites. The trade-off is that you need new patterns for handling corrections—if an event was wrong, you add a compensating event rather than editing history.
When Event Sourcing Shines
Event sourcing isn’t universally better than CRUD. It excels in specific scenarios where its characteristics align with business requirements.
Complete Audit Trails
Financial systems demand knowing not just account balances, but every transaction that contributed to them. Healthcare applications must track who accessed patient records and when. Event sourcing provides audit trails by default—no separate logging infrastructure required. The events are the log.
Compliance frameworks increasingly require this level of traceability. Banking systems where every transaction must be recorded fit event sourcing perfectly, with audit trails coming for free. Rather than bolting audit capabilities onto CRUD systems, event sourcing makes auditability intrinsic to your data model.
Temporal Queries
Questions like “what was this user’s account balance on March 15th?” are trivial with event sourcing—replay events up to that date. In CRUD systems, answering historical queries requires maintaining separate snapshots or time-series tables, adding complexity that event sourcing handles naturally.
This temporal flexibility enables powerful analytics. You can replay events with different business logic to see how changes would have affected historical outcomes. Marketing teams can analyze customer behavior over time. Operations can understand system evolution without relying on incomplete logs.
Business Process Insight
The events can be used as data for a pub-sub system in addition to pure data storage, and event sourcing can be used for integration with other systems. Event streams naturally integrate with message brokers and real-time processing pipelines.
Consider an e-commerce platform tracking abandoned carts. With CRUD, you see final outcomes: some users checked out, others didn’t. Event sourcing reveals the journey: they added items, compared products, applied discount codes, then left. This behavioral data drives better product recommendations and targeted retention campaigns.
System Recovery and Testing
When production issues occur, event sourcing lets you replay events in a test environment to reproduce exact conditions. The event log acts as an excellent record of debugging activities, and if an issue is detected, one can replay the event log in a controlled environment to understand the source of such anomalies.
This capability transforms debugging from guesswork into systematic investigation. You’re not reading through log files trying to reconstruct what happened—you have the actual sequence of state changes that led to the problem.
The Complexity Trade-off
Event sourcing’s benefits come with real costs. Understanding these helps determine whether the pattern fits your context.
Development Complexity
Event-based systems are significantly more complex to design, implement and maintain. For enterprise large systems, the number of possible states and side effects of events can grow to a point that troubleshooting and making changes may be really laborious.
Developers must think in terms of events and state transitions rather than simple CRUD operations. This cognitive shift takes time. Event handlers must be idempotent. Event schemas require careful versioning. The straightforward simplicity of updating a record gives way to considering command validation, event persistence, and projection updates.
Eventual Consistency
Reading current state requires deriving it from events—a process that takes time. This introduces eventual consistency: writes succeed immediately, but reads might lag slightly behind. For some applications, this delay is acceptable. For others, it creates unworkable user experiences.
Systems displaying real-time inventory or account balances often need immediate consistency guarantees that event sourcing complicates. You can work around this with techniques like reading your own writes or maintaining synchronous projections, but these solutions add complexity that undermines event sourcing’s elegance.
Event Schema Evolution
Once events are stored, they’re immutable. But business requirements change. How do you handle a new required field in events that were already persisted without it?
Schema evolution becomes a first-class concern. You need strategies for versioning events, upcasting old formats to new ones on read, or maintaining multiple event versions. Tools and frameworks help, but this remains more complex than simply adding a nullable column to a table.
Operational Overhead
Event sourcing systems have more moving parts. You need an event store, projection builders to maintain read models, and often message brokers to propagate events. Each component requires monitoring, scaling, and maintenance.
For small teams or projects with limited operational maturity, this overhead may outweigh the benefits. CRUD’s simplicity means fewer things can break, and when they do, solutions are well-documented and understood by most developers.
CQRS: The Natural Complement
Command Query Responsibility Segregation (CQRS) separates write operations (commands) from read operations (queries). While independent of event sourcing, the patterns pair naturally.
In CQRS, commands change state by generating events. These events are persisted in the event store. Separately, read models (projections) subscribe to these events and build optimized views for queries.
Why CQRS Fits Event Sourcing
The event store is optimized for appending writes, not complex queries. CQRS decouples the two, allowing writers to update the system without interfering with readers. Read models can be structured however queries need them—relational tables, document stores, search indexes—without constraining how events are stored.
This separation enables independent scaling. Write-heavy workloads scale the command side. Read-heavy workloads scale projections. Each can optimize for its specific access patterns.
Building Read Models
A read model subscribes to the event stream and updates its state as events arrive:
→ Projection: Increment cart count for user 123 Event: ItemRemovedFromCart → Projection: Decrement cart count for user 123
Read models answer specific queries efficiently. You might maintain one projection for user-facing cart displays (fast lookups by user ID), another for admin analytics (aggregate statistics), and a third for recommendation engines (frequently browsed items). Each optimizes for its use case without the compromises that come from querying the event store directly.
Practical Implementation Considerations
Moving from theory to production requires addressing concrete technical challenges.
Choosing an Event Store
Several options exist for persisting events:
Purpose-Built Event Stores like EventStoreDB provide native event sourcing features: stream-based organization, efficient event replay, and projection management. These offer the best developer experience but introduce new infrastructure dependencies.
Relational Databases can serve as event stores using append-only tables. You lose some specialized features but leverage existing operational expertise. Many teams start here to minimize new technology adoption.
Message Brokers like Kafka naturally store ordered event streams. They excel at distributing events to multiple consumers but require additional tooling for querying historical events and managing projections.
The choice depends on your existing infrastructure, team expertise, and specific requirements around querying, scaling, and operational complexity.
Event Granularity
Events can represent different levels of abstraction. Low-level events map closely to CRUD operations: FieldUpdated, RecordCreated. Higher-level business events capture intent: OrderPlaced, PaymentProcessed.
Domain-driven design encourages business-level events that express meaningful actions in your domain language. These events better reflect actual business processes and remain stable even as implementation details change. However, they require deeper domain understanding and careful modeling upfront.
Snapshot Strategy
Replaying thousands of events to derive current state becomes expensive. Snapshots—periodic captures of state—provide optimization points. Instead of replaying all events, you load the most recent snapshot and replay only subsequent events.
The trade-off is added complexity. You must decide when to create snapshots (every N events? periodically?), how to store them, and how to handle snapshot corruption. For aggregates with long histories, snapshots become essential. For short-lived entities, they’re unnecessary overhead.
Migration from CRUD
You can use different strategies for migration, such as dual writes, event capture, or event replay. You also need to handle synchronization, consistency, and performance issues that may arise from having two different data sources.
Gradual migration reduces risk. Start by capturing events alongside CRUD operations without changing read paths. Once comfortable, transition reads to projections. Finally, remove CRUD writes in favor of pure event sourcing. This phased approach lets you validate each step before full commitment.
When CRUD Remains the Better Choice
Event sourcing isn’t always appropriate. Several scenarios favor traditional CRUD approaches.
Simple Domain Models
Applications with straightforward entities and minimal business logic gain little from event sourcing. Content management systems storing articles, employee directories, or configuration settings often operate perfectly well with CRUD. The added complexity of event sourcing provides no compensating value.
Reference Data
Data that changes infrequently and where history doesn’t matter—country codes, currency lists, static lookup tables—fits CRUD naturally. CRUD is useful if the data to be stored does not contain any semantics because it is only raw data, such as in IoT where you have to capture and persist large amounts of sensor data.
Performance-Critical Reads
Systems where read latency must be absolutely minimal may struggle with event sourcing’s eventual consistency. Real-time trading platforms, high-frequency transaction processors, or systems with strict SLA requirements around read performance often need the immediate consistency CRUD provides.
Small Team Capacity
Teams without deep architectural expertise or limited operational resources may find event sourcing’s complexity overwhelming. The learning curve, tooling requirements, and operational overhead demand investment that not all organizations can afford.
Hybrid Approaches: The Pragmatic Middle Ground
Many successful systems employ both patterns selectively. Core business domains where auditability and temporal queries matter use event sourcing. Supporting services and reference data use CRUD.
This hybrid approach optimizes each subsystem for its specific needs. Order processing might be event-sourced while product catalogs remain CRUD. Financial transactions use events while user preference settings use traditional tables. The key is making conscious decisions based on requirements rather than applying one pattern universally.
Bounded Contexts
Domain-driven design’s concept of bounded contexts helps structure hybrid systems. Each bounded context can choose its persistence strategy independently. Context boundaries prevent event sourcing complexity from leaking into CRUD domains and vice versa.
Integration between contexts happens through well-defined interfaces—often events themselves. An order context publishes OrderPlaced events that inventory and shipping contexts consume, regardless of whether those contexts use event sourcing internally.
Measuring Success: Evaluating the Transition
Organizations moving to event sourcing need metrics to assess whether the change delivers expected benefits.
| Metric | What It Measures | Target |
|---|---|---|
| Audit compliance coverage | Percentage of critical operations with full traceability | 100% for regulated operations |
| Temporal query performance | Time to answer historical state questions | Sub-second for recent history |
| Projection lag | Delay between event occurrence and read model update | Milliseconds to seconds depending on SLA |
| Development velocity | Time to implement new features post-migration | Return to baseline within 3-6 months |
| System complexity | Number of components and their interactions | Stable or decreasing after initial increase |
These metrics help validate that event sourcing’s benefits justify its costs in your specific context.
What We’ve Learned
The choice between event sourcing and CRUD isn’t about which pattern is superior—it’s about matching architectural decisions to business requirements and organizational capabilities.
CRUD excels when simplicity, immediate consistency, and developer familiarity matter most. It’s the right default for many applications, particularly those with straightforward domain models where current state suffices.
Event sourcing shines when auditability, temporal analysis, and business process insight justify its complexity. Financial systems, collaborative platforms, and domains where understanding how state evolved matters as much as the state itself benefit from event sourcing’s characteristics.
The key considerations when evaluating event sourcing include:
Audit requirements: Does your domain require complete traceability of all changes? Regulatory compliance often drives this need.
Temporal queries: Do you need to ask questions about historical state frequently enough to justify the infrastructure to support them easily?
System scale and concurrency: Do you face contention issues from high concurrent access that CQRS patterns would alleviate?
Team capability: Does your team have the expertise and capacity to handle event sourcing’s operational complexity?
Domain complexity: Is your business logic rich enough that capturing it as a series of meaningful events provides value?
Successful implementations often start small. Choose a single bounded context where event sourcing’s benefits are clear—perhaps audit-critical operations or a high-concurrency bottleneck. Gain experience with the patterns, tooling, and operational requirements before expanding to other domains.
The trend in enterprise architecture is toward selective use of event sourcing where it provides clear value, combined with CRUD where simplicity suffices. This pragmatic approach acknowledges that different parts of a system have different needs, and architectural patterns should serve business requirements rather than the other way around.
Whether you choose event sourcing, stick with CRUD, or employ a hybrid approach, the decision should emerge from careful analysis of your specific context. The most important step is moving beyond default choices to conscious architectural decisions that align with your actual requirements.
