I’ve been thinking a lot about how modern systems handle massive scale while maintaining data integrity. It’s fascinating how some applications can process millions of events without losing track of what happened and when. This led me to explore event-driven architecture in Node.js, particularly how we can build systems that are both scalable and reliable.

Have you ever wondered how financial systems maintain perfect transaction histories or how e-commerce platforms handle thousands of simultaneous orders without data conflicts? The answer often lies in combining event sourcing with CQRS patterns.

Let me show you how we can implement this in Node.js. We’ll start with the event store, which forms the foundation of our system.

class EventStore {
  async appendEvents(aggregateId: string, events: BaseEvent[]) {
    const client = await this.pool.connect();
    try {
      await client.query('BEGIN');
      
      for (const event of events) {
        const result = await client.query(
          `INSERT INTO events 
           (event_id, event_type, aggregate_id, event_data, stream_version)
           VALUES ($1, $2, $3, $4, $5) 
           RETURNING global_sequence`,
          [event.eventId, event.eventType, aggregateId, 
           event.eventData, event.streamVersion]
        );
      }
      
      await client.query('COMMIT');
    } catch (error) {
      await client.query('ROLLBACK');
      throw error;
    } finally {
      client.release();
    }
  }
}

What happens when multiple processes try to modify the same data simultaneously? This is where optimistic concurrency control comes into play. We check the expected version before committing changes, preventing conflicting modifications.

Now, let’s look at command handling. Commands represent intentions to change the system state, and they’re where the business logic lives.

class CreateOrderHandler {
  async handle(command: CreateOrderCommand) {
    const events = await this.loadEvents(command.orderId);
    const order = OrderAggregate.replay(events);
    
    if (order.canCreate()) {
      const newEvent = order.create(command);
      await this.eventStore.appendEvents(command.orderId, [newEvent]);
      await this.eventBus.publish(newEvent);
    }
  }
}

Notice how we reconstruct the current state by replaying events? This approach gives us a complete history of every change that ever occurred. But what about performance when we have thousands of events for a single entity?

That’s where snapshots come in. Instead of replaying every event, we can periodically save the current state and only replay events that occurred after the last snapshot.

class SnapshotManager {
  async createSnapshot(aggregateId: string, version: number) {
    const events = await this.loadEventsSinceLastSnapshot(aggregateId);
    const state = Aggregate.replay(events);
    
    await this.saveSnapshot({
      aggregateId,
      version,
      state,
      timestamp: new Date()
    });
  }
}

For the read side, we use projections to maintain optimized views of our data. These projections update automatically whenever new events occur, ensuring our queries remain fast and efficient.

class OrderSummaryProjection {
  async onOrderCreated(event: OrderCreatedEvent) {
    await this.db.query(
      `INSERT INTO order_summaries 
       (order_id, customer_id, status, total_amount)
       VALUES ($1, $2, $3, $4)`,
      [event.aggregateId, event.eventData.customerId, 
       'created', 0]
    );
  }
}

How do we ensure all these components work together reliably? We use an event bus with proper retry mechanisms and dead letter queues for handling failures.

Testing is crucial in such systems. We need to verify that commands produce the correct events and that our projections maintain consistency.

describe('Order Creation', () => {
  it('should emit OrderCreated event', async () => {
    const handler = new CreateOrderHandler();
    await handler.handle(testCommand);
    
    const events = await eventStore.getEvents(testOrderId);
    expect(events[0].eventType).toBe('OrderCreated');
  });
});

Building with event sourcing and CQRS requires shifting how we think about data and state. Instead of focusing on the current state, we focus on the sequence of changes that led to that state. This approach provides incredible flexibility and reliability, though it does introduce complexity.

The patterns we’ve discussed enable systems that can scale horizontally while maintaining data consistency and complete audit trails. They’re particularly valuable in domains where data accuracy and historical tracking are critical.

What challenges have you faced with traditional CRUD architectures? Could event sourcing provide solutions to those problems?

I’d love to hear your thoughts and experiences with these patterns. If you found this useful, please share it with others who might benefit from these concepts. Feel free to leave comments or questions below – let’s continue the conversation about building robust, scalable systems with Node.js.