I’ve been thinking a lot about how we build systems that not only work today but remain understandable and maintainable years from now. That’s why I want to share my approach to building type-safe event sourcing systems. This pattern has transformed how I think about data integrity and system evolution.

Have you ever wondered what your application’s state looked like yesterday? Or needed to track exactly how a particular value changed over time? Event sourcing answers these questions by storing every state change as an immutable event.

Let me show you how we can build this with TypeScript’s powerful type system. We start by defining our core domain events with strict typing:

interface UserCreatedEvent {
  type: 'UserCreated';
  aggregateId: string;
  version: number;
  data: {
    email: string;
    username: string;
    hashedPassword: string;
  };
  metadata: {
    timestamp: Date;
    userId: string;
  };
}

Each event becomes a permanent record of something that happened in your system. But how do we ensure these events are stored reliably? PostgreSQL gives us the transactional guarantees we need while allowing efficient querying of event streams.

Here’s how we might set up our event store table:

CREATE TABLE events (
  id UUID PRIMARY KEY,
  aggregate_id VARCHAR(255) NOT NULL,
  event_type VARCHAR(255) NOT NULL,
  event_version INTEGER NOT NULL,
  event_data JSONB NOT NULL,
  metadata JSONB NOT NULL,
  created_at TIMESTAMP DEFAULT NOW(),
  UNIQUE(aggregate_id, event_version)
);

The real power comes when we combine this storage with TypeScript’s type system. We can create handlers that know exactly what type of event they’re processing:

function handleUserCreated(event: UserCreatedEvent): void {
  // TypeScript knows event.data has email, username, hashedPassword
  const { email, username } = event.data;
  createReadModelUser(email, username);
}

What happens when business requirements change and we need to handle events differently? Since we have the complete history, we can rebuild our read models with new logic. This evolutionary capability is one of event sourcing’s strongest features.

Let’s look at how we might handle concurrency. Optimistic locking ensures we don’t overwrite changes:

async function saveEvents(
  aggregateId: string,
  expectedVersion: number,
  newEvents: DomainEvent[]
): Promise<void> {
  const currentVersion = await getCurrentVersion(aggregateId);
  if (currentVersion !== expectedVersion) {
    throw new ConcurrencyError('Version mismatch');
  }
  await storeEvents(newEvents);
}

Testing becomes more straightforward too. We can verify our system’s behavior by replaying events:

test('user email change workflow', async () => {
  const events = [
    createUserCreatedEvent(),
    createEmailChangedEvent()
  ];
  
  await replayEvents(events);
  const user = await getUserReadModel();
  expect(user.email).toEqual('[email protected]');
});

Deployment and monitoring require careful consideration. We need to track event processing latency and ensure our projections stay current. Distributed tracing helps us understand the flow of events through our system.

The beauty of this approach is how it changes your perspective on system design. Instead of asking “what is the current state?”, you start asking “what events led to this state?” This shift in thinking makes systems more robust and understandable.

Have you considered how event sourcing could improve your audit trails? Or how it might simplify debugging production issues? These benefits become apparent once you start working with event-sourced systems.

I’d love to hear your thoughts on this approach. What challenges have you faced with traditional CRUD systems that event sourcing might solve? Share your experiences in the comments below, and if you found this useful, please like and share with others who might benefit from these concepts.