System Design (LLD)Event Sourcing Basics

Event Sourcing Basics

LevelIntermediate

Duration60 mins

TopicEvent Sourcing Basics

4 / 4

Event Sourcing Trade-offs

The Cost of Power

Event sourcing is a powerful architectural pattern—we've established its significant benefits: complete audit trails, temporal queries, reprocessing capabilities, and multiple read models. But architectural decisions must be grounded in trade-off analysis, not enthusiasm.

Every architectural choice involves costs. Event sourcing introduces complexity that traditional CRUD systems avoid. It requires new mental models that your team must internalize. It demands different infrastructure and operational practices. It changes the query patterns your system can efficiently support.

This page provides an honest, balanced examination of event sourcing's trade-offs. Understanding these costs is essential for making sound decisions about when event sourcing is worth its investment—and when simpler approaches are the wiser choice.

What You Will Learn

By the end of this page, you will understand: (1) the inherent complexity costs of event sourcing, (2) operational and infrastructure considerations, (3) scenarios where event sourcing is clearly beneficial or clearly overkill, and (4) strategies for mitigating event sourcing's downsides.

The Complexity Tax

Event sourcing isn't a modest extension of existing patterns—it's a fundamentally different way of thinking about data persistence. This paradigm shift imposes a complexity tax that affects every aspect of development.

Inherent Complexity Costs

•Mental model shift: Developers must think in events, not entities. CRUD intuitions become liabilities. Training and onboarding costs increase.
•Eventual consistency: If using projections for reads, you must design for eventual consistency. UI/UX decisions must account for stale reads.
•Event design discipline: Events must be carefully designed—right granularity, right data, forward-compatible schemas. Mistakes are expensive to fix.
•Increased codebase size: Aggregates, events, projections, handlers—the code surface area grows significantly compared to simple CRUD.
•Testing complexity: Testing event-sourced systems requires testing event handling, projection updates, and temporal scenarios.
•Debugging requires new skills: Instead of querying database state, you trace event streams. This is powerful but unfamiliar.
•Team expertise requirements: Not all developers are familiar with event sourcing. Finding or training skilled engineers adds cost.

complexity-comparison.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
// ============================================================
// COMPARISON: Simple CRUD vs Event Sourced
// ============================================================
 
// ----------------------
// TRADITIONAL CRUD: Simple, direct, familiar
// ----------------------
 
class CrudOrderService {
    async placeOrder(orderData: OrderInput): Promise<Order> {
        // Validate
        if (!orderData.items.length) {
            throw new Error('Order must have items');
        }
        
        // Calculate total
        const total = orderData.items.reduce(
            (sum, item) => sum + (item.quantity * item.price), 0
        );
        
        // Save directly to database - one operation
        const order = await this.db.orders.create({
            customerId: orderData.customerId,
            items: orderData.items,
            total,
            status: 'pending',
            createdAt: new Date(),
        });
        
        return order;
    }
    
    async updateStatus(orderId: string, newStatus: string): Promise<void> {
        // Direct update - one operation
        await this.db.orders.update(orderId, { status: newStatus });
    }
    
    async getOrder(orderId: string): Promise<Order> {
        // Direct read - one operation
        return this.db.orders.findById(orderId);
    }
}
 
// Files: ~1 (just the service)
// Concepts: 3 (Service, Database, Entity)
// Operations: Simple CRUD
 
// ----------------------
// EVENT-SOURCED: Powerful, complex, requires expertise
// ----------------------
 
// Domain Events (new concept)
interface OrderPlaced {
    type: 'OrderPlaced';
    aggregateId: string;
    payload: {
        customerId: string;
        items: OrderItem[];
        total: number;
    };
}
 
interface OrderStatusChanged {
    type: 'OrderStatusChanged';
    aggregateId: string;
    payload: {
        previousStatus: string;
        newStatus: string;
    };
}
 
// Aggregate (new concept, with behavior and state)
class OrderAggregate {
    private _state: OrderState;
    private _uncommittedEvents: OrderEvent[] = [];
    
    static create(command: PlaceOrderCommand): OrderAggregate {
        const order = new OrderAggregate();
        order.applyNew({
            type: 'OrderPlaced',
            aggregateId: command.orderId,
            payload: {
                customerId: command.customerId,
                items: command.items,
                total: command.items.reduce((s, i) => s + i.quantity * i.price, 0),
            },
        });
        return order;
    }
    
    changeStatus(newStatus: string): void {
        // Validation against current state
        if (this._state.status === 'delivered') {
            throw new Error('Cannot change status of delivered order');
        }
        
        this.applyNew({
            type: 'OrderStatusChanged',
            aggregateId: this._state.orderId,
            payload: {
                previousStatus: this._state.status,
                newStatus,
            },
        });
    }
    
    private applyNew(event: OrderEvent): void {
        this.when(event);
        this._uncommittedEvents.push(event);
    }
    
    loadFromHistory(events: OrderEvent[]): void {
        for (const event of events) {
            this.when(event);
        }
    }
    
    private when(event: OrderEvent): void {
        switch (event.type) {
            case 'OrderPlaced':
                this._state = {
                    orderId: event.aggregateId,
                    customerId: event.payload.customerId,
                    items: event.payload.items,
                    total: event.payload.total,
                    status: 'pending',
                };
                break;
            case 'OrderStatusChanged':
                this._state = {
                    ...this._state,
                    status: event.payload.newStatus,
                };
                break;
        }
    }
    
    getUncommittedEvents(): OrderEvent[] {
        return this._uncommittedEvents;
    }
}
 
// Repository (new pattern)
class OrderRepository {
    async getById(orderId: string): Promise<OrderAggregate> {
        const events = await this.eventStore.loadStream(`order-${orderId}`);
        const order = new OrderAggregate();
        order.loadFromHistory(events);
        return order;
    }
    
    async save(order: OrderAggregate): Promise<void> {
        const events = order.getUncommittedEvents();
        await this.eventStore.append(
            `order-${order.state.orderId}`,
            events
        );
    }
}
 
// Application Service (orchestration)
class OrderApplicationService {
    async placeOrder(command: PlaceOrderCommand): Promise<void> {
        // Validation
        if (!command.items.length) {
            throw new Error('Order must have items');
        }
        
        // Create aggregate (generates events)
        const order = OrderAggregate.create(command);
        
        // Save events to event store
        await this.repository.save(order);
    }
    
    async updateStatus(orderId: string, newStatus: string): Promise<void> {
        // Load aggregate from events
        const order = await this.repository.getById(orderId);
        
        // Execute business logic (generates events)
        order.changeStatus(newStatus);
        
        // Save new events
        await this.repository.save(order);
    }
}
 
// Projection for reads (new concept)
class OrderProjection {
    async handle(event: OrderEvent): Promise<void> {
        switch (event.type) {
            case 'OrderPlaced':
                await this.readDb.insert('orders', {
                    order_id: event.aggregateId,
                    customer_id: event.payload.customerId,
                    total: event.payload.total,
                    status: 'pending',
                });
                break;
            case 'OrderStatusChanged':
                await this.readDb.update('orders', 
                    { order_id: event.aggregateId },
                    { status: event.payload.newStatus }
                );
                break;
        }
    }
}
 
// Query Service (reads from projection)
class OrderQueryService {
    async getOrder(orderId: string): Promise<OrderView> {
        return this.readDb.findById('orders', orderId);
    }
}
 
// Files: 5+ (Events, Aggregate, Repository, AppService, Projection, QueryService)
// Concepts: 10+ (Events, Aggregates, Event Store, Projections, Commands, Handlers...)
// Operations: Complex event workflow

The Complexity is Real

The code comparison above isn't hyperbole—event sourcing genuinely requires more code, more concepts, and more careful design. This complexity must be justified by clear benefits. If you're building a simple CRUD app, this complexity is pure overhead.

Eventual Consistency Challenges

When reads come from projections (which is typical for complex queries), those projections may lag behind the event stream. This eventual consistency creates UX and business logic challenges that traditional CRUD systems don't face.

eventual-consistency-problems.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
// ============================================================
// PROBLEM: User submits form, doesn't see their change
// ============================================================
 
// User creates an order
async function handleOrderSubmission(userId: string, orderData: OrderInput) {
    // 1. Command is processed
    await orderService.placeOrder(orderData);
    
    // 2. Event is appended to event store (fast)
    // OrderPlaced event is now in the stream
    
    // 3. Projection receives event and updates read model (async)
    // This might take 50ms, 500ms, or even longer under load
    
    // 4. User is redirected to "My Orders" page
    redirect('/my-orders');
}
 
// "My Orders" page handler
async function getMyOrders(userId: string) {
    // Query the projection
    const orders = await orderQueryService.getOrdersForUser(userId);
    
    // PROBLEM: The new order might not be in the projection yet!
    // User sees "You have 3 orders" but expected 4
    // User thinks: "Did my order go through?"
    
    return orders;
}
 
// ============================================================
// MITIGATION STRATEGIES
// ============================================================
 
// Strategy 1: Optimistic UI (show what the user expects)
async function handleOrderSubmissionOptimistic(userId: string, orderData: OrderInput) {
    const orderId = await orderService.placeOrder(orderData);
    
    // Redirect with the new order ID for optimistic display
    redirect(`/my-orders?newOrderId=${orderId}`);
}
 
async function getMyOrdersOptimistic(userId: string, newOrderId?: string) {
    const orders = await orderQueryService.getOrdersForUser(userId);
    
    if (newOrderId && !orders.find(o => o.id === newOrderId)) {
        // The new order isn't in the projection yet
        // Add a placeholder so the user sees immediate feedback
        orders.unshift({
            id: newOrderId,
            status: 'processing',
            message: 'Your order is being processed...',
            isOptimistic: true, // UI can style this differently
        });
    }
    
    return orders;
}
 
// Strategy 2: Synchronous projection update for commands
async function placeOrderWithSyncRead(userId: string, orderData: OrderInput) {
    const orderId = await orderService.placeOrder(orderData);
    
    // Wait for this specific event to be projected
    await pollUntilProjected('orders', orderId, { maxWaitMs: 2000 });
    
    // Now the redirect will show the new order
    redirect('/my-orders');
}
 
async function pollUntilProjected(
    collection: string, 
    id: string, 
    options: { maxWaitMs: number }
): Promise<boolean> {
    const startTime = Date.now();
    
    while (Date.now() - startTime < options.maxWaitMs) {
        const record = await readDb.findById(collection, id);
        if (record) return true;
        
        await sleep(50); // Poll every 50ms
    }
    
    // Timed out but we still proceed - eventual consistency wins
    return false;
}
 
// Strategy 3: Read-your-writes from the aggregate (not projection)
async function getOrderAfterCreation(orderId: string) {
    // Instead of reading from projection, read from event stream
    // This is always consistent with what was just written
    const order = await orderRepository.getById(orderId);
    return order.state;
}
 
// Strategy 4: Command returns read model (for specific cases)
interface CommandResult<T> {
    success: boolean;
    resultData: T; // Include read model in response
}
 
async function placeOrderWithResult(orderData: OrderInput): Promise<CommandResult<OrderView>> {
    const order = OrderAggregate.create(orderData);
    await orderRepository.save(order);
    
    // Return a view of the aggregate, bypassing projection
    return {
        success: true,
        resultData: {
            orderId: order.state.orderId,
            status: order.state.status,
            total: order.state.total,
            items: order.state.items,
        },
    };
}

Eventual Consistency Mitigation Strategies
Strategy	Complexity	User Experience	Best For
Optimistic UI	Medium	Instant feedback, may show stale data	Non-critical displays, social features
Poll until projected	Low	Slight delay, guaranteed consistency	Critical confirmation screens
Read from aggregate	Low	Consistent but limited data	Simple entity reads, post-command
Command returns data	Medium	Consistent, may duplicate logic	Forms with immediate confirmation

Embrace the Trade-off Consciously

Eventual consistency isn't a bug—it's a trade-off for scalability and flexibility. But your UX design must account for it. Users who expect CRUD-style immediate consistency will be confused if you don't handle this explicitly.

Operational Considerations

Event-sourced systems have different operational characteristics than traditional databases. Your operations team needs new skills, new tools, and new procedures.

Operational Challenges

•Storage growth: Events accumulate forever (by design). Storage requirements grow indefinitely with activity. Plan for this.
•Backup and restore complexity: Restoring involves both the event store and potentially multiple projection databases.
•Projection rebuilds: When projections fail or need schema changes, rebuilding can take hours or days for large event stores.
•Monitoring differs: Traditional database metrics don't capture event store health. You need projection lag, event throughput, replay time.
•Debugging requires different tools: Standard database query tools don't help. You need event stream viewers, replay debuggers.
•Data corrections are complex: You can't just UPDATE a row. Corrections require compensating events and careful reasoning.

operational-concerns.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
// ============================================================
// STORAGE GROWTH MANAGEMENT
// ============================================================
 
// Problem: Event store grows forever
// After 5 years, you might have billions of events
 
// Solution 1: Event archiving (move old events to cold storage)
class EventArchiver {
    async archiveOldEvents(olderThan: Date): Promise<ArchiveResult> {
        // Move events to cheap cold storage (S3, Glacier, etc.)
        const eventsToArchive = await this.eventStore.getEventsBefore(olderThan);
        
        await this.coldStorage.write(eventsToArchive);
        await this.eventStore.markArchived(eventsToArchive);
        
        // Update snapshots to serve as "starting point" for archived aggregates
        for (const aggregateId of this.getAffectedAggregates(eventsToArchive)) {
            await this.createArchiveSnapshot(aggregateId, olderThan);
        }
        
        return { archivedCount: eventsToArchive.length };
    }
    
    // When loading an old aggregate, check for archived events
    async loadAggregateWithArchive(id: string): Promise<Aggregate> {
        const snapshot = await this.snapshotStore.getLatest(id);
        
        if (snapshot?.isArchiveSnapshot) {
            // Events before this snapshot are in cold storage
            // Only load events after the snapshot
            const recentEvents = await this.eventStore.loadStream(id, snapshot.version + 1);
            return this.rehydrate(snapshot.state, recentEvents);
        }
        
        // Normal path for recent aggregates
        const allEvents = await this.eventStore.loadStream(id);
        return this.rehydrate(null, allEvents);
    }
}
 
// Solution 2: Aggregate snapshotting with event compaction
// For very old aggregates, replace events with a single "StateRestored" event
class EventCompactor {
    async compactAggregate(aggregateId: string, beforeVersion: number): Promise<void> {
        // Load current state up to the compaction point
        const events = await this.eventStore.loadStream(aggregateId, 1, beforeVersion);
        const state = this.rehydrate(events);
        
        // Create a synthetic event that represents the compacted state
        const compactionEvent: StateRestored = {
            type: 'StateRestored',
            aggregateId,
            version: 1,
            payload: { restoredState: state, compactedEventCount: events.length },
            isCompactionEvent: true,
        };
        
        // In a new stream or same stream with tombstoning
        await this.eventStore.replaceEvents(aggregateId, 1, beforeVersion, compactionEvent);
        
        console.log(`Compacted ${events.length} events into 1 for ${aggregateId}`);
    }
}
 
// ============================================================
// PROJECTION REBUILDING
// ============================================================
 
class ProjectionRebuildService {
    async rebuild(projectionName: string): Promise<RebuildResult> {
        const projection = this.projections.get(projectionName);
        const startTime = Date.now();
        
        console.log(`Starting rebuild for projection: ${projectionName}`);
        
        // Step 1: Create new projection table (avoid downtime)
        const newTableName = `${projection.tableName}_rebuild_${Date.now()}`;
        await this.db.createTable(newTableName, projection.schema);
        
        // Step 2: Replay all events
        let eventCount = 0;
        const eventStream = this.eventStore.streamAll();
        
        for await (const event of eventStream) {
            await projection.handleToTable(newTableName, event);
            eventCount++;
            
            if (eventCount % 100000 === 0) {
                console.log(`Processed ${eventCount} events...`);
            }
        }
        
        // Step 3: Catch up with events that arrived during rebuild
        // (This window should be small and fast)
        await this.catchUpFromLiveStream(projection, newTableName);
        
        // Step 4: Atomic table swap
        await this.db.renameTable(projection.tableName, `${projection.tableName}_old`);
        await this.db.renameTable(newTableName, projection.tableName);
        await this.db.dropTable(`${projection.tableName}_old`);
        
        const duration = (Date.now() - startTime) / 1000;
        console.log(`Rebuild complete: ${eventCount} events in ${duration}s`);
        
        return { eventCount, durationSeconds: duration };
    }
}
 
// ============================================================
// ESSENTIAL MONITORING METRICS
// ============================================================
 
interface EventSourcingMetrics {
    // Event Store Health
    eventAppendLatencyP99: number;  // Latency to append events
    eventStoreSize: number;         // Total storage used
    eventsPerSecond: number;        // Throughput
    
    // Projection Health
    projectionLag: Map<string, number>;   // Events behind for each projection
    projectionThroughput: Map<string, number>; // Events/sec each projection processes
    projectionErrors: Map<string, number>;     // Errors per projection
    
    // Aggregate Health
    aggregateLoadTimeP99: number;   // Time to load (rehydrate) aggregates
    snapshotHitRate: number;        // % of loads using snapshots
    eventsPerAggregate: number;     // Average events per aggregate (growth indicator)
    
    // Operational Signals
    projectionRebuildTime: Map<string, number>; // How long to rebuild each projection
    oldestEventAge: Date;           // Age of oldest non-archived event
}
 
function alertOnAnomalies(metrics: EventSourcingMetrics): void {
    // Alert if projections fall too far behind
    for (const [name, lag] of metrics.projectionLag) {
        if (lag > 10000) {
            alert(`Projection ${name} is ${lag} events behind!`);
        }
    }
    
    // Alert if aggregate load times are growing
    if (metrics.aggregateLoadTimeP99 > 500) {
        alert(`Aggregate load latency is high (${metrics.aggregateLoadTimeP99}ms). Consider more aggressive snapshotting.`);
    }
    
    // Alert if event store is growing unexpectedly fast
    // (Might indicate a bug producing excessive events)
    if (metrics.eventsPerSecond > EXPECTED_MAX_EVENTS_PER_SECOND * 2) {
        alert(`Event rate is abnormally high: ${metrics.eventsPerSecond}/s`);
    }
}

Plan for Operations from Day One

Operational concerns aren't afterthoughts—they should influence your initial design. Build in monitoring, archiving capabilities, and projection rebuild tooling before you need them. The time to discover your rebuilds take 12 hours is not during an outage.

Query Pattern Limitations

Event stores are optimized for a specific access pattern: append-only writes and stream-based reads. Complex ad-hoc queries that are trivial in SQL become difficult or impossible directly on the event store.

Query Pattern Comparison
Query Type	Traditional SQL	Event Store (Direct)	Event Store (With Projections)
Get entity by ID	✅ Simple SELECT	✅ Load stream, replay	✅ Simple SELECT on projection
Filter by attribute	✅ WHERE clause	❌ Must scan all events	✅ WHERE on projection
Aggregate (SUM, COUNT)	✅ GROUP BY	❌ Must compute by replaying	✅ Pre-computed in projection
Join across entities	✅ JOIN	❌ Must load multiple streams	✅ Denormalize in projection
Full-text search	✅ LIKE, indexes	❌ Not supported	⚠️ Use Elasticsearch projection
Ad-hoc exploration	✅ Any SQL query	❌ Must build projections first	⚠️ Limited by projection design

The projection requirement:

Every query pattern you need must have a corresponding projection—or you must be willing to replay events on demand (which is slow for analytical queries). This means:

You must anticipate queries: Unlike SQL where you can query any column, projections must be designed and built.
Adding queries requires development: A new dashboard metric might require building a new projection and waiting for it to process the entire history.
Schema changes are expensive: Changing a projection's schema may require rebuilding from scratch.

For applications with well-defined query patterns, this is manageable. For applications requiring flexible ad-hoc querying (business intelligence, analytics), the projection overhead can be significant.

Not Suitable for Analytics-First Applications

If your application's primary purpose is ad-hoc data exploration and flexible analytics, event sourcing may not be the best persistence model. Consider using event sourcing for the transactional core and streaming events to a traditional data warehouse for analytics.

When Event Sourcing is Worth the Investment

Despite the complexity costs, event sourcing provides significant value in specific contexts. The key is matching the pattern to problems where its benefits clearly outweigh its costs.

Strong Fit: Event Sourcing Recommended

•Regulatory audit requirements: Financial, healthcare, legal domains where complete trails are mandated
•Temporal queries are core: Insurance claims, legal disputes needing 'state at time T'
•Event-driven integrations: Systems naturally communicating via events
•Multiple read models needed: Different views for different stakeholders
•Complex domain logic: Where domain modeling with aggregates provides clarity
•Debugging history is critical: Fraud detection, incident investigation
•Reprocessing anticipated: Business rules that evolve and need retroactive application

Poor Fit: CRUD Likely Better

•Simple CRUD applications: Blogs, basic CMS, simple data entry
•History not valuable: When only current state matters
•Team lacks expertise: If training cost exceeds project budget
•Tight deadlines: Event sourcing takes longer to implement properly
•Ad-hoc analytics primary use: Data exploration is the main purpose
•Strong consistency required: Systems unable to tolerate eventual consistency
•Low-volume, low-complexity: Overhead not justified by scale

Decision Framework: Event Sourcing Suitability
Factor	Favor Event Sourcing	Favor Traditional CRUD
Audit requirements	Mandated, detailed trails	Basic or none
Temporal queries	Frequent, core to business	Rare or unnecessary
Domain complexity	Rich, aggregate-centric	Data-centric, simple
Integration style	Event-driven, async	Request/response, sync
Team experience	Experienced with patterns	Traditional backgrounds
Timeline	Long-term investment OK	Ship fast, iterate later
Read patterns	Well-known, predictable	Ad-hoc, exploratory

The Strategic vs Tactical Decision

Event sourcing is a strategic choice that pays dividends over years. If you're building a short-lived prototype or a system with uncertain requirements, simpler approaches let you move faster. If you're building a core business system that will evolve for a decade, event sourcing's benefits compound.

Mitigation Strategies: Getting Benefits with Less Pain

If event sourcing is the right choice for your context, several strategies can mitigate its downsides:

Practical Mitigation Strategies

•Start with one bounded context: Don't event-source your entire system. Apply it to the domain where benefits are clearest; use CRUD elsewhere.
•Use proven event store products: Don't build your own. EventStoreDB, Axon, Marten have solved operational problems you haven't thought of yet.
•Invest in tooling early: Event viewers, projection rebuilders, replay debuggers pay for themselves quickly.
•Design events carefully from day one: Additive fields, versioning, semantic naming. Events are forever; get them right.
•Accept synchronous projections for some use cases: For read-after-write consistency, updating a projection in the same transaction is simpler than distributed eventual consistency.
•Snapshot aggressively: Long aggregates hurt performance. Snapshot early, snapshot often.
•Stream events to analytics platforms: Don't try to do analytics on the event store. Send events to Snowflake, BigQuery, or a data warehouse.
•Train your team: Invest in education. Event sourcing requires a mental shift that doesn't happen by osmosis.

pragmatic-approaches.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
// ============================================================
// HYBRID APPROACH: Event sourcing where it matters, CRUD elsewhere
// ============================================================
 
// Example: E-commerce system
// - Orders: Event-sourced (audit trails, complex state machine, integrations)
// - Product Catalog: CRUD (simple data, no history needed)
// - User Preferences: CRUD (low-value, high-frequency updates)
 
// Order module - full event sourcing
class OrderModule {
    constructor(
        private eventStore: EventStore,
        private projectionEngine: ProjectionEngine
    ) {}
    
    // Rich domain model, events, projections - the full pattern
}
 
// Product Catalog - simple CRUD
class ProductCatalogModule {
    constructor(private db: Database) {}
    
    async updateProduct(id: string, data: ProductData): Promise<void> {
        // Simple, direct database update
        await this.db.products.update(id, data);
    }
}
 
// The two modules can coexist
// Events from Orders can trigger updates in Product Catalog if needed
 
// ============================================================
// SIMPLIFIED PROJECTION: In-transaction update for read-after-write
// ============================================================
 
class OrderService {
    async placeOrder(command: PlaceOrderCommand): Promise<OrderView> {
        return await this.db.transaction(async (tx) => {
            // 1. Append event to event store
            const event = this.createOrderPlacedEvent(command);
            await this.eventStore.append(event, tx);
            
            // 2. Update projection in same transaction
            // This gives immediate consistency for this single projection
            const view = this.projectToView(event);
            await this.orderViewTable.insert(view, tx);
            
            // 3. Return the view - user sees their order immediately
            return view;
        });
        
        // Other projections (analytics, reports) still update asynchronously
        // This is a pragmatic trade-off: simple consistency where users need it,
        // eventual consistency for secondary concerns
    }
}
 
// ============================================================
// GRADUAL ADOPTION: Start with event logging, evolve to sourcing
// ============================================================
 
// Phase 1: Traditional CRUD with event logging
class OrderServicePhase1 {
    async updateOrderStatus(orderId: string, newStatus: string): Promise<void> {
        // Primary storage is still the database
        const order = await this.db.orders.findById(orderId);
        const oldStatus = order.status;
        
        await this.db.orders.update(orderId, { status: newStatus });
        
        // But we also log events for eventual migration
        await this.eventLog.append({
            type: 'OrderStatusChanged',
            aggregateId: orderId,
            payload: { oldStatus, newStatus },
        });
        
        // Events are currently secondary - used for analytics, debugging
        // But we're building the event history we'll need later
    }
}
 
// Phase 2: Derive some read models from events
class OrderServicePhase2 {
    async updateOrderStatus(orderId: string, newStatus: string): Promise<void> {
        const order = await this.repository.getById(orderId);
        order.updateStatus(newStatus);
        await this.repository.save(order); // Appends event
        
        // Database is still updated for backward compatibility
        await this.db.orders.update(orderId, { status: newStatus });
        
        // But now some read models come from projections
        // Analytics dashboard: from projections
        // Order lookup: still from primary DB
    }
}
 
// Phase 3: Full event sourcing (optional)
// Only if Phase 2 proves valuable and team is confident

Pragmatism Over Purity

The goal isn't architectural purity—it's solving business problems effectively. Hybrid approaches that mix event sourcing with traditional patterns often provide the best risk/reward ratio. Apply event sourcing where it provides clear value; use simpler approaches elsewhere.

Summary: Making Informed Trade-off Decisions

We've examined event sourcing's trade-offs through an honest, balanced lens. Let's consolidate the key insights for making informed architectural decisions:

Key Trade-off Summary

•Complexity is real and significant: Event sourcing requires more code, new concepts, and different mental models. The complexity tax must be justified by clear benefits.
•Eventual consistency demands UX consideration: Projections may lag. Design your user experience to handle this gracefully.
•Operations differ fundamentally: Storage growth, projection rebuilds, and monitoring require new skills and tools.
•Query patterns must be anticipated: Unlike SQL, you can't easily query what you didn't project. Plan your read models.
•Strong fit scenarios exist: Audit requirements, temporal queries, event-driven integration—these justify the investment.
•Simple CRUD still wins for simple problems: Not everything needs event sourcing. Match tools to problems.
•Hybrid approaches are valid: Event-source where valuable, use CRUD elsewhere. Pragmatism over purity.
•The investment compounds over time: For long-lived systems, event sourcing's benefits grow as the event history becomes an irreplaceable asset.

Making the decision:

Event sourcing is a strategic investment. It has significant upfront costs—complexity, learning curves, infrastructure—but provides powerful long-term capabilities. The decision should be driven by:

Business requirements: Are audit trails, temporal queries, or reprocessing genuinely needed?
Team capability: Does your team have (or can acquire) the expertise?
System lifespan: Will the system live long enough for the investment to pay off?
Problem fit: Does the domain naturally model as events?

If the answers favor event sourcing, invest in doing it properly. If not, simpler approaches are not failures—they're appropriate engineering choices.

Module Complete: Event Sourcing Basics

You now have a comprehensive understanding of event sourcing: its fundamental concepts, events as source of truth, state reconstruction mechanics, and trade-offs. You can evaluate when event sourcing is appropriate and how to mitigate its downsides. This foundation prepares you for deeper exploration of event-driven architectures.

4 / 4

Loading learning content...

System Design (LLD)Event Sourcing Basics

Event Sourcing Basics

LevelIntermediate

Duration60 mins

TopicEvent Sourcing Basics

4 / 4

Event Sourcing Trade-offs

The Cost of Power

What You Will Learn

The Complexity Tax

Inherent Complexity Costs

•Mental model shift: Developers must think in events, not entities. CRUD intuitions become liabilities. Training and onboarding costs increase.
•Eventual consistency: If using projections for reads, you must design for eventual consistency. UI/UX decisions must account for stale reads.
•Event design discipline: Events must be carefully designed—right granularity, right data, forward-compatible schemas. Mistakes are expensive to fix.
•Increased codebase size: Aggregates, events, projections, handlers—the code surface area grows significantly compared to simple CRUD.
•Testing complexity: Testing event-sourced systems requires testing event handling, projection updates, and temporal scenarios.
•Debugging requires new skills: Instead of querying database state, you trace event streams. This is powerful but unfamiliar.
•Team expertise requirements: Not all developers are familiar with event sourcing. Finding or training skilled engineers adds cost.

complexity-comparison.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
// ============================================================
// COMPARISON: Simple CRUD vs Event Sourced
// ============================================================
 
// ----------------------
// TRADITIONAL CRUD: Simple, direct, familiar
// ----------------------
 
class CrudOrderService {
    async placeOrder(orderData: OrderInput): Promise<Order> {
        // Validate
        if (!orderData.items.length) {
            throw new Error('Order must have items');
        }
        
        // Calculate total
        const total = orderData.items.reduce(
            (sum, item) => sum + (item.quantity * item.price), 0
        );
        
        // Save directly to database - one operation
        const order = await this.db.orders.create({
            customerId: orderData.customerId,
            items: orderData.items,
            total,
            status: 'pending',
            createdAt: new Date(),
        });
        
        return order;
    }
    
    async updateStatus(orderId: string, newStatus: string): Promise<void> {
        // Direct update - one operation
        await this.db.orders.update(orderId, { status: newStatus });
    }
    
    async getOrder(orderId: string): Promise<Order> {
        // Direct read - one operation
        return this.db.orders.findById(orderId);
    }
}
 
// Files: ~1 (just the service)
// Concepts: 3 (Service, Database, Entity)
// Operations: Simple CRUD
 
// ----------------------
// EVENT-SOURCED: Powerful, complex, requires expertise
// ----------------------
 
// Domain Events (new concept)
interface OrderPlaced {
    type: 'OrderPlaced';
    aggregateId: string;
    payload: {
        customerId: string;
        items: OrderItem[];
        total: number;
    };
}
 
interface OrderStatusChanged {
    type: 'OrderStatusChanged';
    aggregateId: string;
    payload: {
        previousStatus: string;
        newStatus: string;
    };
}
 
// Aggregate (new concept, with behavior and state)
class OrderAggregate {
    private _state: OrderState;
    private _uncommittedEvents: OrderEvent[] = [];
    
    static create(command: PlaceOrderCommand): OrderAggregate {
        const order = new OrderAggregate();
        order.applyNew({
            type: 'OrderPlaced',
            aggregateId: command.orderId,
            payload: {
                customerId: command.customerId,
                items: command.items,
                total: command.items.reduce((s, i) => s + i.quantity * i.price, 0),
            },
        });
        return order;
    }
    
    changeStatus(newStatus: string): void {
        // Validation against current state
        if (this._state.status === 'delivered') {
            throw new Error('Cannot change status of delivered order');
        }
        
        this.applyNew({
            type: 'OrderStatusChanged',
            aggregateId: this._state.orderId,
            payload: {
                previousStatus: this._state.status,
                newStatus,
            },
        });
    }
    
    private applyNew(event: OrderEvent): void {
        this.when(event);
        this._uncommittedEvents.push(event);
    }
    
    loadFromHistory(events: OrderEvent[]): void {
        for (const event of events) {
            this.when(event);
        }
    }
    
    private when(event: OrderEvent): void {
        switch (event.type) {
            case 'OrderPlaced':
                this._state = {
                    orderId: event.aggregateId,
                    customerId: event.payload.customerId,
                    items: event.payload.items,
                    total: event.payload.total,
                    status: 'pending',
                };
                break;
            case 'OrderStatusChanged':
                this._state = {
                    ...this._state,
                    status: event.payload.newStatus,
                };
                break;
        }
    }
    
    getUncommittedEvents(): OrderEvent[] {
        return this._uncommittedEvents;
    }
}
 
// Repository (new pattern)
class OrderRepository {
    async getById(orderId: string): Promise<OrderAggregate> {
        const events = await this.eventStore.loadStream(`order-${orderId}`);
        const order = new OrderAggregate();
        order.loadFromHistory(events);
        return order;
    }
    
    async save(order: OrderAggregate): Promise<void> {
        const events = order.getUncommittedEvents();
        await this.eventStore.append(
            `order-${order.state.orderId}`,
            events
        );
    }
}
 
// Application Service (orchestration)
class OrderApplicationService {
    async placeOrder(command: PlaceOrderCommand): Promise<void> {
        // Validation
        if (!command.items.length) {
            throw new Error('Order must have items');
        }
        
        // Create aggregate (generates events)
        const order = OrderAggregate.create(command);
        
        // Save events to event store
        await this.repository.save(order);
    }
    
    async updateStatus(orderId: string, newStatus: string): Promise<void> {
        // Load aggregate from events
        const order = await this.repository.getById(orderId);
        
        // Execute business logic (generates events)
        order.changeStatus(newStatus);
        
        // Save new events
        await this.repository.save(order);
    }
}
 
// Projection for reads (new concept)
class OrderProjection {
    async handle(event: OrderEvent): Promise<void> {
        switch (event.type) {
            case 'OrderPlaced':
                await this.readDb.insert('orders', {
                    order_id: event.aggregateId,
                    customer_id: event.payload.customerId,
                    total: event.payload.total,
                    status: 'pending',
                });
                break;
            case 'OrderStatusChanged':
                await this.readDb.update('orders', 
                    { order_id: event.aggregateId },
                    { status: event.payload.newStatus }
                );
                break;
        }
    }
}
 
// Query Service (reads from projection)
class OrderQueryService {
    async getOrder(orderId: string): Promise<OrderView> {
        return this.readDb.findById('orders', orderId);
    }
}
 
// Files: 5+ (Events, Aggregate, Repository, AppService, Projection, QueryService)
// Concepts: 10+ (Events, Aggregates, Event Store, Projections, Commands, Handlers...)
// Operations: Complex event workflow

The Complexity is Real

Eventual Consistency Challenges

eventual-consistency-problems.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
// ============================================================
// PROBLEM: User submits form, doesn't see their change
// ============================================================
 
// User creates an order
async function handleOrderSubmission(userId: string, orderData: OrderInput) {
    // 1. Command is processed
    await orderService.placeOrder(orderData);
    
    // 2. Event is appended to event store (fast)
    // OrderPlaced event is now in the stream
    
    // 3. Projection receives event and updates read model (async)
    // This might take 50ms, 500ms, or even longer under load
    
    // 4. User is redirected to "My Orders" page
    redirect('/my-orders');
}
 
// "My Orders" page handler
async function getMyOrders(userId: string) {
    // Query the projection
    const orders = await orderQueryService.getOrdersForUser(userId);
    
    // PROBLEM: The new order might not be in the projection yet!
    // User sees "You have 3 orders" but expected 4
    // User thinks: "Did my order go through?"
    
    return orders;
}
 
// ============================================================
// MITIGATION STRATEGIES
// ============================================================
 
// Strategy 1: Optimistic UI (show what the user expects)
async function handleOrderSubmissionOptimistic(userId: string, orderData: OrderInput) {
    const orderId = await orderService.placeOrder(orderData);
    
    // Redirect with the new order ID for optimistic display
    redirect(`/my-orders?newOrderId=${orderId}`);
}
 
async function getMyOrdersOptimistic(userId: string, newOrderId?: string) {
    const orders = await orderQueryService.getOrdersForUser(userId);
    
    if (newOrderId && !orders.find(o => o.id === newOrderId)) {
        // The new order isn't in the projection yet
        // Add a placeholder so the user sees immediate feedback
        orders.unshift({
            id: newOrderId,
            status: 'processing',
            message: 'Your order is being processed...',
            isOptimistic: true, // UI can style this differently
        });
    }
    
    return orders;
}
 
// Strategy 2: Synchronous projection update for commands
async function placeOrderWithSyncRead(userId: string, orderData: OrderInput) {
    const orderId = await orderService.placeOrder(orderData);
    
    // Wait for this specific event to be projected
    await pollUntilProjected('orders', orderId, { maxWaitMs: 2000 });
    
    // Now the redirect will show the new order
    redirect('/my-orders');
}
 
async function pollUntilProjected(
    collection: string, 
    id: string, 
    options: { maxWaitMs: number }
): Promise<boolean> {
    const startTime = Date.now();
    
    while (Date.now() - startTime < options.maxWaitMs) {
        const record = await readDb.findById(collection, id);
        if (record) return true;
        
        await sleep(50); // Poll every 50ms
    }
    
    // Timed out but we still proceed - eventual consistency wins
    return false;
}
 
// Strategy 3: Read-your-writes from the aggregate (not projection)
async function getOrderAfterCreation(orderId: string) {
    // Instead of reading from projection, read from event stream
    // This is always consistent with what was just written
    const order = await orderRepository.getById(orderId);
    return order.state;
}
 
// Strategy 4: Command returns read model (for specific cases)
interface CommandResult<T> {
    success: boolean;
    resultData: T; // Include read model in response
}
 
async function placeOrderWithResult(orderData: OrderInput): Promise<CommandResult<OrderView>> {
    const order = OrderAggregate.create(orderData);
    await orderRepository.save(order);
    
    // Return a view of the aggregate, bypassing projection
    return {
        success: true,
        resultData: {
            orderId: order.state.orderId,
            status: order.state.status,
            total: order.state.total,
            items: order.state.items,
        },
    };
}

Eventual Consistency Mitigation Strategies
Strategy	Complexity	User Experience	Best For
Optimistic UI	Medium	Instant feedback, may show stale data	Non-critical displays, social features
Poll until projected	Low	Slight delay, guaranteed consistency	Critical confirmation screens
Read from aggregate	Low	Consistent but limited data	Simple entity reads, post-command
Command returns data	Medium	Consistent, may duplicate logic	Forms with immediate confirmation

Embrace the Trade-off Consciously

Operational Considerations

Event-sourced systems have different operational characteristics than traditional databases. Your operations team needs new skills, new tools, and new procedures.

Operational Challenges

•Storage growth: Events accumulate forever (by design). Storage requirements grow indefinitely with activity. Plan for this.
•Backup and restore complexity: Restoring involves both the event store and potentially multiple projection databases.
•Projection rebuilds: When projections fail or need schema changes, rebuilding can take hours or days for large event stores.
•Monitoring differs: Traditional database metrics don't capture event store health. You need projection lag, event throughput, replay time.
•Debugging requires different tools: Standard database query tools don't help. You need event stream viewers, replay debuggers.
•Data corrections are complex: You can't just UPDATE a row. Corrections require compensating events and careful reasoning.

operational-concerns.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
// ============================================================
// STORAGE GROWTH MANAGEMENT
// ============================================================
 
// Problem: Event store grows forever
// After 5 years, you might have billions of events
 
// Solution 1: Event archiving (move old events to cold storage)
class EventArchiver {
    async archiveOldEvents(olderThan: Date): Promise<ArchiveResult> {
        // Move events to cheap cold storage (S3, Glacier, etc.)
        const eventsToArchive = await this.eventStore.getEventsBefore(olderThan);
        
        await this.coldStorage.write(eventsToArchive);
        await this.eventStore.markArchived(eventsToArchive);
        
        // Update snapshots to serve as "starting point" for archived aggregates
        for (const aggregateId of this.getAffectedAggregates(eventsToArchive)) {
            await this.createArchiveSnapshot(aggregateId, olderThan);
        }
        
        return { archivedCount: eventsToArchive.length };
    }
    
    // When loading an old aggregate, check for archived events
    async loadAggregateWithArchive(id: string): Promise<Aggregate> {
        const snapshot = await this.snapshotStore.getLatest(id);
        
        if (snapshot?.isArchiveSnapshot) {
            // Events before this snapshot are in cold storage
            // Only load events after the snapshot
            const recentEvents = await this.eventStore.loadStream(id, snapshot.version + 1);
            return this.rehydrate(snapshot.state, recentEvents);
        }
        
        // Normal path for recent aggregates
        const allEvents = await this.eventStore.loadStream(id);
        return this.rehydrate(null, allEvents);
    }
}
 
// Solution 2: Aggregate snapshotting with event compaction
// For very old aggregates, replace events with a single "StateRestored" event
class EventCompactor {
    async compactAggregate(aggregateId: string, beforeVersion: number): Promise<void> {
        // Load current state up to the compaction point
        const events = await this.eventStore.loadStream(aggregateId, 1, beforeVersion);
        const state = this.rehydrate(events);
        
        // Create a synthetic event that represents the compacted state
        const compactionEvent: StateRestored = {
            type: 'StateRestored',
            aggregateId,
            version: 1,
            payload: { restoredState: state, compactedEventCount: events.length },
            isCompactionEvent: true,
        };
        
        // In a new stream or same stream with tombstoning
        await this.eventStore.replaceEvents(aggregateId, 1, beforeVersion, compactionEvent);
        
        console.log(`Compacted ${events.length} events into 1 for ${aggregateId}`);
    }
}
 
// ============================================================
// PROJECTION REBUILDING
// ============================================================
 
class ProjectionRebuildService {
    async rebuild(projectionName: string): Promise<RebuildResult> {
        const projection = this.projections.get(projectionName);
        const startTime = Date.now();
        
        console.log(`Starting rebuild for projection: ${projectionName}`);
        
        // Step 1: Create new projection table (avoid downtime)
        const newTableName = `${projection.tableName}_rebuild_${Date.now()}`;
        await this.db.createTable(newTableName, projection.schema);
        
        // Step 2: Replay all events
        let eventCount = 0;
        const eventStream = this.eventStore.streamAll();
        
        for await (const event of eventStream) {
            await projection.handleToTable(newTableName, event);
            eventCount++;
            
            if (eventCount % 100000 === 0) {
                console.log(`Processed ${eventCount} events...`);
            }
        }
        
        // Step 3: Catch up with events that arrived during rebuild
        // (This window should be small and fast)
        await this.catchUpFromLiveStream(projection, newTableName);
        
        // Step 4: Atomic table swap
        await this.db.renameTable(projection.tableName, `${projection.tableName}_old`);
        await this.db.renameTable(newTableName, projection.tableName);
        await this.db.dropTable(`${projection.tableName}_old`);
        
        const duration = (Date.now() - startTime) / 1000;
        console.log(`Rebuild complete: ${eventCount} events in ${duration}s`);
        
        return { eventCount, durationSeconds: duration };
    }
}
 
// ============================================================
// ESSENTIAL MONITORING METRICS
// ============================================================
 
interface EventSourcingMetrics {
    // Event Store Health
    eventAppendLatencyP99: number;  // Latency to append events
    eventStoreSize: number;         // Total storage used
    eventsPerSecond: number;        // Throughput
    
    // Projection Health
    projectionLag: Map<string, number>;   // Events behind for each projection
    projectionThroughput: Map<string, number>; // Events/sec each projection processes
    projectionErrors: Map<string, number>;     // Errors per projection
    
    // Aggregate Health
    aggregateLoadTimeP99: number;   // Time to load (rehydrate) aggregates
    snapshotHitRate: number;        // % of loads using snapshots
    eventsPerAggregate: number;     // Average events per aggregate (growth indicator)
    
    // Operational Signals
    projectionRebuildTime: Map<string, number>; // How long to rebuild each projection
    oldestEventAge: Date;           // Age of oldest non-archived event
}
 
function alertOnAnomalies(metrics: EventSourcingMetrics): void {
    // Alert if projections fall too far behind
    for (const [name, lag] of metrics.projectionLag) {
        if (lag > 10000) {
            alert(`Projection ${name} is ${lag} events behind!`);
        }
    }
    
    // Alert if aggregate load times are growing
    if (metrics.aggregateLoadTimeP99 > 500) {
        alert(`Aggregate load latency is high (${metrics.aggregateLoadTimeP99}ms). Consider more aggressive snapshotting.`);
    }
    
    // Alert if event store is growing unexpectedly fast
    // (Might indicate a bug producing excessive events)
    if (metrics.eventsPerSecond > EXPECTED_MAX_EVENTS_PER_SECOND * 2) {
        alert(`Event rate is abnormally high: ${metrics.eventsPerSecond}/s`);
    }
}

Plan for Operations from Day One

Query Pattern Limitations

Query Pattern Comparison
Query Type	Traditional SQL	Event Store (Direct)	Event Store (With Projections)
Get entity by ID	✅ Simple SELECT	✅ Load stream, replay	✅ Simple SELECT on projection
Filter by attribute	✅ WHERE clause	❌ Must scan all events	✅ WHERE on projection
Aggregate (SUM, COUNT)	✅ GROUP BY	❌ Must compute by replaying	✅ Pre-computed in projection
Join across entities	✅ JOIN	❌ Must load multiple streams	✅ Denormalize in projection
Full-text search	✅ LIKE, indexes	❌ Not supported	⚠️ Use Elasticsearch projection
Ad-hoc exploration	✅ Any SQL query	❌ Must build projections first	⚠️ Limited by projection design

The projection requirement:

Every query pattern you need must have a corresponding projection—or you must be willing to replay events on demand (which is slow for analytical queries). This means:

You must anticipate queries: Unlike SQL where you can query any column, projections must be designed and built.
Adding queries requires development: A new dashboard metric might require building a new projection and waiting for it to process the entire history.
Schema changes are expensive: Changing a projection's schema may require rebuilding from scratch.

Not Suitable for Analytics-First Applications

When Event Sourcing is Worth the Investment

Despite the complexity costs, event sourcing provides significant value in specific contexts. The key is matching the pattern to problems where its benefits clearly outweigh its costs.

Strong Fit: Event Sourcing Recommended

•Regulatory audit requirements: Financial, healthcare, legal domains where complete trails are mandated
•Temporal queries are core: Insurance claims, legal disputes needing 'state at time T'
•Event-driven integrations: Systems naturally communicating via events
•Multiple read models needed: Different views for different stakeholders
•Complex domain logic: Where domain modeling with aggregates provides clarity
•Debugging history is critical: Fraud detection, incident investigation
•Reprocessing anticipated: Business rules that evolve and need retroactive application

Poor Fit: CRUD Likely Better

•Simple CRUD applications: Blogs, basic CMS, simple data entry
•History not valuable: When only current state matters
•Team lacks expertise: If training cost exceeds project budget
•Tight deadlines: Event sourcing takes longer to implement properly
•Ad-hoc analytics primary use: Data exploration is the main purpose
•Strong consistency required: Systems unable to tolerate eventual consistency
•Low-volume, low-complexity: Overhead not justified by scale

Decision Framework: Event Sourcing Suitability
Factor	Favor Event Sourcing	Favor Traditional CRUD
Audit requirements	Mandated, detailed trails	Basic or none
Temporal queries	Frequent, core to business	Rare or unnecessary
Domain complexity	Rich, aggregate-centric	Data-centric, simple
Integration style	Event-driven, async	Request/response, sync
Team experience	Experienced with patterns	Traditional backgrounds
Timeline	Long-term investment OK	Ship fast, iterate later
Read patterns	Well-known, predictable	Ad-hoc, exploratory

The Strategic vs Tactical Decision

Mitigation Strategies: Getting Benefits with Less Pain

If event sourcing is the right choice for your context, several strategies can mitigate its downsides:

Practical Mitigation Strategies

•Start with one bounded context: Don't event-source your entire system. Apply it to the domain where benefits are clearest; use CRUD elsewhere.
•Use proven event store products: Don't build your own. EventStoreDB, Axon, Marten have solved operational problems you haven't thought of yet.
•Invest in tooling early: Event viewers, projection rebuilders, replay debuggers pay for themselves quickly.
•Design events carefully from day one: Additive fields, versioning, semantic naming. Events are forever; get them right.
•Accept synchronous projections for some use cases: For read-after-write consistency, updating a projection in the same transaction is simpler than distributed eventual consistency.
•Snapshot aggressively: Long aggregates hurt performance. Snapshot early, snapshot often.
•Stream events to analytics platforms: Don't try to do analytics on the event store. Send events to Snowflake, BigQuery, or a data warehouse.
•Train your team: Invest in education. Event sourcing requires a mental shift that doesn't happen by osmosis.

pragmatic-approaches.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
// ============================================================
// HYBRID APPROACH: Event sourcing where it matters, CRUD elsewhere
// ============================================================
 
// Example: E-commerce system
// - Orders: Event-sourced (audit trails, complex state machine, integrations)
// - Product Catalog: CRUD (simple data, no history needed)
// - User Preferences: CRUD (low-value, high-frequency updates)
 
// Order module - full event sourcing
class OrderModule {
    constructor(
        private eventStore: EventStore,
        private projectionEngine: ProjectionEngine
    ) {}
    
    // Rich domain model, events, projections - the full pattern
}
 
// Product Catalog - simple CRUD
class ProductCatalogModule {
    constructor(private db: Database) {}
    
    async updateProduct(id: string, data: ProductData): Promise<void> {
        // Simple, direct database update
        await this.db.products.update(id, data);
    }
}
 
// The two modules can coexist
// Events from Orders can trigger updates in Product Catalog if needed
 
// ============================================================
// SIMPLIFIED PROJECTION: In-transaction update for read-after-write
// ============================================================
 
class OrderService {
    async placeOrder(command: PlaceOrderCommand): Promise<OrderView> {
        return await this.db.transaction(async (tx) => {
            // 1. Append event to event store
            const event = this.createOrderPlacedEvent(command);
            await this.eventStore.append(event, tx);
            
            // 2. Update projection in same transaction
            // This gives immediate consistency for this single projection
            const view = this.projectToView(event);
            await this.orderViewTable.insert(view, tx);
            
            // 3. Return the view - user sees their order immediately
            return view;
        });
        
        // Other projections (analytics, reports) still update asynchronously
        // This is a pragmatic trade-off: simple consistency where users need it,
        // eventual consistency for secondary concerns
    }
}
 
// ============================================================
// GRADUAL ADOPTION: Start with event logging, evolve to sourcing
// ============================================================
 
// Phase 1: Traditional CRUD with event logging
class OrderServicePhase1 {
    async updateOrderStatus(orderId: string, newStatus: string): Promise<void> {
        // Primary storage is still the database
        const order = await this.db.orders.findById(orderId);
        const oldStatus = order.status;
        
        await this.db.orders.update(orderId, { status: newStatus });
        
        // But we also log events for eventual migration
        await this.eventLog.append({
            type: 'OrderStatusChanged',
            aggregateId: orderId,
            payload: { oldStatus, newStatus },
        });
        
        // Events are currently secondary - used for analytics, debugging
        // But we're building the event history we'll need later
    }
}
 
// Phase 2: Derive some read models from events
class OrderServicePhase2 {
    async updateOrderStatus(orderId: string, newStatus: string): Promise<void> {
        const order = await this.repository.getById(orderId);
        order.updateStatus(newStatus);
        await this.repository.save(order); // Appends event
        
        // Database is still updated for backward compatibility
        await this.db.orders.update(orderId, { status: newStatus });
        
        // But now some read models come from projections
        // Analytics dashboard: from projections
        // Order lookup: still from primary DB
    }
}
 
// Phase 3: Full event sourcing (optional)
// Only if Phase 2 proves valuable and team is confident

Pragmatism Over Purity

Summary: Making Informed Trade-off Decisions

We've examined event sourcing's trade-offs through an honest, balanced lens. Let's consolidate the key insights for making informed architectural decisions:

Key Trade-off Summary

•Complexity is real and significant: Event sourcing requires more code, new concepts, and different mental models. The complexity tax must be justified by clear benefits.
•Eventual consistency demands UX consideration: Projections may lag. Design your user experience to handle this gracefully.
•Operations differ fundamentally: Storage growth, projection rebuilds, and monitoring require new skills and tools.
•Query patterns must be anticipated: Unlike SQL, you can't easily query what you didn't project. Plan your read models.
•Strong fit scenarios exist: Audit requirements, temporal queries, event-driven integration—these justify the investment.
•Simple CRUD still wins for simple problems: Not everything needs event sourcing. Match tools to problems.
•Hybrid approaches are valid: Event-source where valuable, use CRUD elsewhere. Pragmatism over purity.
•The investment compounds over time: For long-lived systems, event sourcing's benefits grow as the event history becomes an irreplaceable asset.

Making the decision:

Business requirements: Are audit trails, temporal queries, or reprocessing genuinely needed?
Team capability: Does your team have (or can acquire) the expertise?
System lifespan: Will the system live long enough for the investment to pay off?
Problem fit: Does the domain naturally model as events?

If the answers favor event sourcing, invest in doing it properly. If not, simpler approaches are not failures—they're appropriate engineering choices.

Module Complete: Event Sourcing Basics

4 / 4

Event Sourcing Basics - Page 4 of 4 | OneNoughtOne