Event Sourcing - Learning Module

Loading content...

0/273

Event Store Design

The Heart of Event Sourcing

If events are the source of truth, then the event store is the vault that protects that truth. An event store is not just another database—it's a specialized storage system designed around the unique requirements of event sourcing: append-only writes, ordered reads, stream partitioning, and optimistic concurrency.

Choosing or designing an event store is one of the most consequential architectural decisions in an event-sourced system. Get it right, and you have a foundation that scales elegantly. Get it wrong, and you'll spend years fighting storage limitations, ordering bugs, and performance bottlenecks.

What You Will Learn

By the end of this page, you will understand the core requirements of an event store, different storage models and their tradeoffs, partitioning and ordering strategies, how to implement optimistic concurrency, and the critical decision of building versus buying an event store solution.

Core Requirements of an Event Store

An event store must satisfy several critical requirements that distinguish it from general-purpose databases. Understanding these requirements is essential whether you're building a custom solution or evaluating existing products.

Essential Event Store Capabilities

•Append-only semantics — Events can only be added, never updated or deleted. The store must enforce this immutability at the storage level, not just the application level.
•Ordered reading by stream — Events within a single stream must be readable in exact write order. Global ordering across streams is desirable but often relaxed for scalability.
•Optimistic concurrency control — Writers must be able to specify expected stream version and fail if another write has occurred, enabling lock-free atomic updates.
•Efficient stream reading — Reading all events for a single aggregate (stream) must be fast, even if the global event count is in the billions.
•Subscription/notification support — Consumers need to be notified of new events for projections, often with exactly-once or at-least-once delivery guarantees.
•Durable and consistent — Events, once acknowledged, must never be lost. The store must survive crashes, restarts, and hardware failures.
•Metadata and causation tracking — Events should carry rich metadata for debugging, tracing, and correlation across distributed systems.

Event Store vs Traditional Database Operations
Operation	Traditional Database	Event Store
Create	INSERT row	APPEND event(s) to stream
Read current state	SELECT row	READ stream + FOLD events
Update	UPDATE row	APPEND new event(s)
Delete	DELETE row	APPEND 'deleted' event
Concurrency	Pessimistic locks or OCC on row version	OCC on stream version
Query by field	WHERE clause on any column	Requires separate projection/index
Historical state	Not supported without audit table	Built-in: read up to point in time

Why Not Just Use PostgreSQL?

You can implement event sourcing on PostgreSQL or any RDBMS—and many teams do successfully. However, general-purpose databases require careful schema design, manual ordering guarantees, and custom subscription mechanisms. Purpose-built event stores provide these out of the box with optimized implementations.

Storage Models

Event stores can be implemented using various underlying storage models. Each has different tradeoffs for write throughput, read patterns, scalability, and operational complexity.

Single Table Model

The simplest approach: store all events in one large table with stream ID, sequence number, and event data columns.

Schema:

CREATE TABLE events (
  global_position BIGSERIAL PRIMARY KEY,
  stream_id VARCHAR(255) NOT NULL,
  stream_position INTEGER NOT NULL,
  event_type VARCHAR(255) NOT NULL,
  event_data JSONB NOT NULL,
  metadata JSONB,
  created_at TIMESTAMPTZ DEFAULT NOW(),
  UNIQUE (stream_id, stream_position)
);

CREATE INDEX idx_events_stream ON events (stream_id, stream_position);

Pros:

Simple to understand and implement
Easy global ordering via global_position
Transaction support for multi-event appends
Works well up to tens of millions of events

Cons:

Single table becomes a bottleneck at scale
Index maintenance overhead as table grows
No natural partitioning
All streams compete for same write resources

Stream Organization and Naming

How you organize and name streams has significant implications for querying, access control, and evolution. A well-designed stream naming convention provides natural categorization and enables efficient filtering.

stream-naming.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
// Stream naming conventions
 
// Pattern 1: {AggregateType}-{AggregateId}
// Simple and widely used
const orderStream = "Order-ord_12345";
const accountStream = "Account-acct_67890";
const inventoryStream = "Inventory-sku_abc123";
 
// Pattern 2: {Category}/{AggregateType}/{AggregateId}
// Enables category-based projections and access control
const orderStream2 = "commerce/Order/ord_12345";
const shippingStream = "logistics/Shipment/ship_99999";
const userStream = "identity/User/usr_44444";
 
// Pattern 3: Hierarchical with tenant isolation
// Multi-tenant systems benefit from tenant prefix
const tenantOrderStream = "tenant_acme/Order/ord_12345";
const tenantUserStream = "tenant_globex/User/usr_88888";
 
// Category streams (virtual streams aggregating by type)
// EventStoreDB provides this via $ce-{category} system projections
const allOrdersCategory = "$ce-Order";  // All Order events
const allAccountsCategory = "$ce-Account";
 
// Utility functions for stream management
interface StreamId {
  aggregateType: string;
  aggregateId: string;
  category?: string;
  tenant?: string;
}
 
function buildStreamId(params: StreamId): string {
  const parts: string[] = [];
  
  if (params.tenant) {
    parts.push(params.tenant);
  }
  if (params.category) {
    parts.push(params.category);
  }
  parts.push(params.aggregateType);
  parts.push(params.aggregateId);
  
  return parts.join('/');
}
 
function parseStreamId(streamId: string): StreamId {
  const parts = streamId.split('/');
  
  // Handle different formats
  if (parts.length === 2) {
    // Simple: Type/Id or Type-Id
    const [type, id] = parts[0].includes('-') 
      ? parts[0].split('-') 
      : parts;
    return { aggregateType: type, aggregateId: id };
  }
  
  if (parts.length === 3) {
    // With category: category/Type/Id
    return {
      category: parts[0],
      aggregateType: parts[1],
      aggregateId: parts[2],
    };
  }
  
  if (parts.length === 4) {
    // With tenant: tenant/category/Type/Id
    return {
      tenant: parts[0],
      category: parts[1],
      aggregateType: parts[2],
      aggregateId: parts[3],
    };
  }
  
  throw new Error(`Invalid stream ID format: ${streamId}`);
}
 
// Stream filtering by pattern
async function readStreamsByPattern(
  eventStore: EventStore,
  pattern: string
): Promise<Event[][]> {
  // Examples:
  // "Order-*" - all Order streams
  // "tenant_acme/*" - all streams for tenant
  // "*/Shipment/*" - all shipments across tenants
  
  const matchingStreamIds = await eventStore.listStreams({ pattern });
  return Promise.all(
    matchingStreamIds.map(id => eventStore.readStream(id))
  );
}

Stream Naming Best Practices

Use consistent, hierarchical naming that enables pattern-based queries. Include tenant/category prefixes if you'll need to filter by them. Avoid embedding mutable data (like user names) in stream IDs—use stable identifiers. Consider URL-style naming (slashes) for readability and tooling compatibility.

Optimistic Concurrency Control

Optimistic concurrency is the mechanism that enables event sourcing to work correctly in concurrent environments. When appending events, the writer specifies the expected current version of the stream. If another writer has appended events in the meantime, the append fails, forcing the writer to reload and retry.

This is fundamentally different from pessimistic locking (which blocks writers) and is essential for the high-throughput, low-latency characteristics of event-sourced systems.

Converting Mermaid diagram...

optimistic-concurrency.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
// Optimistic concurrency implementation
 
interface AppendResult {
  success: boolean;
  newVersion?: number;
  error?: 'WrongExpectedVersion' | 'StreamNotFound' | 'Unknown';
  currentVersion?: number;
}
 
interface EventStore {
  append(
    streamId: string,
    events: DomainEvent[],
    expectedVersion: number | 'any' | 'noStream'
  ): Promise<AppendResult>;
  
  readStream(streamId: string): Promise<{ events: DomainEvent[]; version: number }>;
}
 
// Command handler with optimistic concurrency and retry
async function handleCommand<TAggregate extends Aggregate>(
  eventStore: EventStore,
  aggregateType: new (id: string) => TAggregate,
  aggregateId: string,
  command: Command,
  maxRetries: number = 3
): Promise<void> {
  let lastError: Error | null = null;
  
  for (let attempt = 1; attempt <= maxRetries; attempt++) {
    try {
      // 1. Load current state
      const { events, version } = await eventStore.readStream(aggregateId);
      
      // 2. Rehydrate aggregate
      const aggregate = new aggregateType(aggregateId);
      aggregate.loadFromHistory(events);
      
      // 3. Execute command (produces new events)
      aggregate.handle(command);
      
      // 4. Get uncommitted events
      const newEvents = aggregate.getUncommittedEvents();
      
      if (newEvents.length === 0) {
        return; // No changes needed
      }
      
      // 5. Attempt to append with expected version
      const result = await eventStore.append(
        aggregateId,
        newEvents,
        version // Expected version from our read
      );
      
      if (result.success) {
        console.log(`Command succeeded, new version: ${result.newVersion}`);
        return;
      }
      
      if (result.error === 'WrongExpectedVersion') {
        console.log(
          `Concurrency conflict on attempt ${attempt}. ` +
          `Expected: ${version}, Current: ${result.currentVersion}. Retrying...`
        );
        lastError = new Error('WrongExpectedVersion');
        continue; // Retry with fresh state
      }
      
      throw new Error(result.error);
      
    } catch (error) {
      lastError = error as Error;
      if (attempt === maxRetries) break;
    }
  }
  
  throw new Error(
    `Failed to handle command after ${maxRetries} attempts: ${lastError?.message}`
  );
}
 
// Special version constants
const ExpectedVersion = {
  // Stream must not exist (for creating new aggregates)
  NoStream: -1,
  
  // Any version is acceptable (dangerous: skips concurrency check)
  Any: -2,
  
  // Stream must exist (any version)
  StreamExists: -4,
} as const;
 
// Usage examples
async function examples(eventStore: EventStore) {
  // Create new aggregate (stream must not exist)
  await eventStore.append(
    'Order-new123',
    [orderCreatedEvent],
    ExpectedVersion.NoStream
  );
  
  // Append to existing (with concurrency check)
  const { version } = await eventStore.readStream('Order-existing456');
  await eventStore.append(
    'Order-existing456',
    [orderUpdatedEvent],
    version
  );
  
  // Idempotent append (when you don't care about conflicts)
  // Use sparingly - usually indicates design issue
  await eventStore.append(
    'Order-any789',
    [logEvent],
    ExpectedVersion.Any
  );
}

Avoid 'Any' Version in Business Logic

Using ExpectedVersion.Any bypasses concurrency protection and can lead to data corruption in business aggregates. It's acceptable for append-only logs (telemetry, analytics) but should be avoided for domain aggregates where business invariants matter.

Subscriptions and Projections

An event store isn't just a write destination—it's also a source for downstream consumers that build read models, trigger integrations, and synchronize external systems. This is accomplished through subscriptions: mechanisms for efficiently reading new events as they're written.

Subscription Types

•Catch-up Subscription — Reads from a specific position, processes all events from there to 'now', then continues following the stream live. Essential for building projections from scratch.
•Live Subscription — Only receives new events written after the subscription starts. Useful for real-time notifications but loses events if the consumer is offline.
•Persistent Subscription — Server-side tracking of consumer position. If the consumer disconnects and reconnects, it resumes from where it left off. Supports consumer groups for competing consumers.
•Polling Subscription — Client periodically queries for events newer than its last position. Simple to implement but higher latency and server load compared to push-based approaches.

subscriptions.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
// Subscription patterns for event processing
 
interface Subscription {
  start(): void;
  stop(): Promise<void>;
}
 
interface SubscriptionOptions {
  fromPosition: number | 'start' | 'end';
  batchSize?: number;
  onEvent: (event: StoredEvent) => Promise<void>;
  onError: (error: Error) => void;
  checkpointInterval?: number;
}
 
// Catch-up subscription with checkpointing
class CatchUpSubscription implements Subscription {
  private position: number;
  private running = false;
  private checkpointStore: CheckpointStore;
  
  constructor(
    private eventStore: EventStore,
    private streamPattern: string,
    private options: SubscriptionOptions,
    checkpointStore: CheckpointStore
  ) {
    this.checkpointStore = checkpointStore;
  }
  
  async start(): Promise<void> {
    // Load last checkpoint
    this.position = await this.checkpointStore.getPosition(
      this.streamPattern
    ) ?? (
      this.options.fromPosition === 'start' ? 0 :
      this.options.fromPosition === 'end' ? await this.eventStore.getLatestPosition() :
      this.options.fromPosition
    );
    
    this.running = true;
    await this.processLoop();
  }
  
  private async processLoop(): Promise<void> {
    let eventsProcessed = 0;
    
    while (this.running) {
      try {
        // Read batch of events
        const events = await this.eventStore.readForward(
          this.streamPattern,
          this.position + 1,
          this.options.batchSize ?? 100
        );
        
        if (events.length === 0) {
          // No new events, wait before polling again
          await sleep(100);
          continue;
        }
        
        // Process each event
        for (const event of events) {
          await this.options.onEvent(event);
          this.position = event.globalPosition;
          eventsProcessed++;
          
          // Checkpoint periodically
          if (eventsProcessed % (this.options.checkpointInterval ?? 100) === 0) {
            await this.checkpointStore.savePosition(
              this.streamPattern,
              this.position
            );
          }
        }
        
      } catch (error) {
        this.options.onError(error as Error);
        await sleep(1000); // Back off on error
      }
    }
  }
  
  async stop(): Promise<void> {
    this.running = false;
    // Final checkpoint
    await this.checkpointStore.savePosition(
      this.streamPattern,
      this.position
    );
  }
}
 
// Projection manager using subscriptions
class ProjectionManager {
  private projections = new Map<string, Projection>();
  
  registerProjection(projection: Projection): void {
    this.projections.set(projection.name, projection);
  }
  
  async rebuildProjection(name: string): Promise<void> {
    const projection = this.projections.get(name);
    if (!projection) throw new Error(`Unknown projection: ${name}`);
    
    console.log(`Rebuilding projection: ${name}`);
    
    // Clear existing read model
    await projection.reset();
    
    // Replay all events from beginning
    const subscription = new CatchUpSubscription(
      this.eventStore,
      projection.streamPattern,
      {
        fromPosition: 'start',
        onEvent: async (event) => {
          await projection.apply(event);
        },
        onError: (error) => {
          console.error(`Projection error: ${error.message}`);
        },
      },
      this.checkpointStore
    );
    
    // Wait until caught up, then switch to live
    await subscription.start();
    console.log(`Projection ${name} rebuilt and running live`);
  }
}
 
// Example: Building an order summary read model
const orderSummaryProjection: Projection = {
  name: 'OrderSummary',
  streamPattern: '$ce-Order',  // All Order category events
  
  async apply(event: StoredEvent): Promise<void> {
    switch (event.eventType) {
      case 'OrderPlaced': {
        const data = event.payload as OrderPlacedPayload;
        await db.insert('order_summaries').values({
          orderId: event.aggregateId,
          customerId: data.customerId,
          status: 'pending',
          totalAmount: data.totalAmount,
          itemCount: data.items.length,
          createdAt: event.occurredAt,
          lastUpdated: event.occurredAt,
        });
        break;
      }
      
      case 'PaymentReceived':
        await db.update('order_summaries')
          .set({ status: 'paid', lastUpdated: event.occurredAt })
          .where({ orderId: event.aggregateId });
        break;
        
      case 'OrderShipped':
        await db.update('order_summaries')
          .set({ status: 'shipped', lastUpdated: event.occurredAt })
          .where({ orderId: event.aggregateId });
        break;
    }
  },
  
  async reset(): Promise<void> {
    await db.delete('order_summaries').execute();
  },
};

Idempotent Projections

Design projections to be idempotent—processing the same event multiple times should produce the same result. This allows safe replay after failures. Use upsert operations where possible, and store event position with projection rows to detect duplicates.

Ordering and Consistency Guarantees

Ordering is critical in event sourcing—events must be processed in the correct sequence to reconstruct valid state. However, different ordering guarantees have vastly different scalability implications.

Ordering Guarantee Levels
Level	Guarantee	Scalability	Use Case
Per-Stream	Events ordered within single stream	Excellent: horizontal scaling	Default for aggregate streams
Per-Category	Events ordered within category (e.g., all Orders)	Moderate: limited parallelism	Projections needing cross-aggregate ordering
Global	All events globally ordered	Limited: single writer bottleneck	Full audit logs, compliance

Per-stream ordering is almost always sufficient for aggregate operations and most projections. Global ordering is expensive and rarely necessary.

Causation and correlation IDs help when you need to understand relationships between events across streams without strict global ordering:

Correlation ID: Links all events triggered by the same initial request
Causation ID: Points to the specific event that caused this event

With these, you can reconstruct the causal chain without global ordering.

causal-ordering.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
// Causal ordering through metadata
 
interface EventMetadata {
  // Unique ID for this event
  eventId: string;
  
  // Links related events across a distributed operation
  // All events from same user action share correlationId
  correlationId: string;
  
  // ID of the event that directly caused this event
  // Creates a DAG of causation
  causationId: string;
  
  // Stream position for this specific stream
  streamPosition: number;
  
  // Global position in the event store (if available)
  globalPosition?: number;
}
 
// Example: Order flow with causal chain
// User places order -> Payment processed -> Inventory reserved -> Shipment created
 
const events = [
  {
    eventId: "evt_001",
    eventType: "OrderPlaced",
    streamId: "Order-123",
    metadata: {
      correlationId: "corr_user_request_abc",
      causationId: "cmd_place_order_xyz",  // The command that triggered this
      streamPosition: 1,
      globalPosition: 1001,
    },
  },
  {
    eventId: "evt_002",
    eventType: "PaymentProcessed",
    streamId: "Payment-456",
    metadata: {
      correlationId: "corr_user_request_abc",  // Same correlation
      causationId: "evt_001",  // Caused by OrderPlaced
      streamPosition: 1,
      globalPosition: 1005,  // Later global position
    },
  },
  {
    eventId: "evt_003",
    eventType: "InventoryReserved",
    streamId: "Inventory-789",
    metadata: {
      correlationId: "corr_user_request_abc",
      causationId: "evt_002",  // Caused by PaymentProcessed
      streamPosition: 15,
      globalPosition: 1008,
    },
  },
  {
    eventId: "evt_004",
    eventType: "ShipmentCreated",
    streamId: "Shipment-999",
    metadata: {
      correlationId: "corr_user_request_abc",
      causationId: "evt_003",  // Caused by InventoryReserved
      streamPosition: 1,
      globalPosition: 1012,
    },
  },
];
 
// Reconstruct causal chain for debugging
function buildCausalChain(
  events: StoredEvent[],
  correlationId: string
): Map<string, StoredEvent[]> {
  // Group events by correlation
  const correlated = events.filter(
    e => e.metadata.correlationId === correlationId
  );
  
  // Build causation tree
  const byEventId = new Map(correlated.map(e => [e.eventId, e]));
  const chain = new Map<string, StoredEvent[]>();
  
  for (const event of correlated) {
    const cause = event.metadata.causationId;
    if (!chain.has(cause)) {
      chain.set(cause, []);
    }
    chain.get(cause)!.push(event);
  }
  
  return chain;
}
 
// Print causal chain for debugging
function printCausalChain(
  chain: Map<string, StoredEvent[]>,
  rootId: string,
  indent = 0
): void {
  const effects = chain.get(rootId) || [];
  for (const event of effects) {
    console.log(`${'  '.repeat(indent)}-> [${event.streamId}] ${event.eventType}`);
    printCausalChain(chain, event.eventId, indent + 1);
  }
}
 
// Output:
// -> [Order-123] OrderPlaced
//   -> [Payment-456] PaymentProcessed
//     -> [Inventory-789] InventoryReserved
//       -> [Shipment-999] ShipmentCreated

Build vs Buy Decision

One of the most significant decisions is whether to build your own event store on a general-purpose database or adopt a purpose-built solution. Both paths have legitimate use cases.

Build on PostgreSQL/MySQL

•✓ Leverage existing operational expertise
•✓ Use familiar backup, monitoring, scaling tools
•✓ Single database for events + read models
•✓ Full control over schema and queries
•✓ No additional licensing costs
•✗ Must implement subscriptions yourself
•✗ Manual optimistic concurrency
•✗ May hit scale limits earlier
•✗ No built-in projections engine

Dedicated: EventStoreDB

•✓ Purpose-built for event sourcing
•✓ Built-in subscriptions and projections
•✓ Native optimistic concurrency
•✓ Optimized indexing for stream reads
•✓ Active community and support
•✗ New infrastructure to learn/operate
•✗ Separate database from read models
•✗ May have licensing considerations
•✗ Less mainstream tooling ecosystem

Decision Matrix for Event Store Selection
Factor	Build (RDBMS)	Buy (EventStoreDB)	Recommendation
Team experience	Strong SQL, new to ES	Willing to learn new tool	Start with SQL if team is new to ES
Scale expectations	<10M events/year	100M events/year	Purpose-built scales easier
Subscription criticality	Simple, batch OK	Real-time, competing consumers	EventStoreDB excels here
Operational constraints	Must minimize infra	Can add new databases	SQL if infra is constrained
Budget	Tight	Available	SQL is cheaper initially
Timeline	Prototype/MVP	Production system	SQL for speed, migrate later

Start Simple, Migrate Later

If uncertain, start with PostgreSQL. The schema is simple, and you can migrate events to a purpose-built store later if needed. The event format is what matters—the storage can be swapped. Facebook, LinkedIn, and many others run event-sourced systems on PostgreSQL-based stores.

Summary: Event Store Design

We've covered the essential aspects of designing and selecting an event store. Let's consolidate the key insights:

Key Takeaways

•Event stores have unique requirements — Append-only semantics, per-stream ordering, optimistic concurrency, and efficient subscriptions distinguish them from general-purpose databases.
•Multiple storage models exist — Single table, partitioned tables, Kafka-style logs, and purpose-built stores each have different tradeoff profiles for scale and complexity.
•Stream naming matters — Hierarchical, consistent naming enables filtering, access control, and category-based projections.
•Optimistic concurrency is essential — Writers specify expected versions; conflicts trigger reload-and-retry, enabling lock-free updates.
•Subscriptions power read models — Catch-up, persistent, and live subscriptions allow consumers to build projections and trigger integrations.
•Per-stream ordering is usually sufficient — Global ordering is expensive; use correlation/causation IDs for cross-stream relationships.
•Build vs buy depends on context — PostgreSQL is a valid starting point; purpose-built stores excel at scale and real-time subscriptions.

What's next:

With events stored durably, we need to reconstruct current state efficiently. The next page explores rebuilding state from events—the mechanics of rehydration, the cost of long event streams, and strategies for handling aggregates with thousands of events.

Page Complete

You now understand the architecture and design considerations for event stores. Whether building on PostgreSQL or adopting EventStoreDB, you know the essential requirements: append-only storage, ordered reads, optimistic concurrency, and efficient subscriptions. Next, we'll explore how to efficiently rebuild state from these event streams.