I’ve been building microservices for years, and one persistent challenge keeps resurfacing: how do we maintain data consistency across distributed systems while preserving a complete history of changes? Traditional approaches often left gaps in audit trails and made it difficult to reconstruct system state. That’s what led me to explore event sourcing with NestJS, EventStore, and Redis. In this guide, I’ll walk you through building a robust system that handles these challenges elegantly.
Event sourcing fundamentally changed how I think about data persistence. Instead of storing only the current state, we persist the entire sequence of events that led to that state. This approach provides an immutable audit trail and enables powerful features like time travel debugging. Have you ever needed to know exactly what happened in your system three months ago? With event sourcing, that information is always available.
Let me show you how to set up the foundation. We’ll create a monorepo structure for our e-commerce microservices:
mkdir event-sourcing-microservices
cd event-sourcing-microservices
mkdir -p services/{user-service,order-service}
mkdir -p shared/{event-store,types}Our shared types package defines the contract between services. This ensures consistency across our distributed system:
// shared/types/src/events/base.ts
export interface BaseEvent {
id: string;
aggregateId: string;
aggregateVersion: number;
eventType: string;
eventData: any;
metadata: {
timestamp: Date;
userId?: string;
};
}
// shared/types/src/events/user-events.ts
export interface UserCreatedEvent extends BaseEvent {
eventType: 'UserCreated';
eventData: {
email: string;
firstName: string;
lastName: string;
};
}Why do we need such detailed event definitions? They serve as the single source of truth for our domain logic. Every state change begins with an event.
Now let’s set up our infrastructure using Docker. This gives us reproducible development environments:
# docker-compose.yml
services:
eventstore:
image: eventstore/eventstore:23.10.0-bookworm-slim
ports: ["1113:1113", "2113:2113"]
environment:
- EVENTSTORE_INSECURE=true
redis:
image: redis:7.2-alpine
ports: ["6379:6379"]EventStoreDB becomes our system of record, while Redis handles real-time communication between services. Have you considered how you’ll handle event ordering in a distributed system?
The core of our system is the event store service. This handles reading and writing events consistently:
// shared/event-store/src/event-store.service.ts
import { EventStoreDBClient } from '@eventstore/db-client';
@Injectable()
export class EventStoreService {
private client: EventStoreDBClient;
async appendToStream(
streamName: string,
events: BaseEvent[]
): Promise<void> {
const serializedEvents = events.map(event =>
jsonEvent({
type: event.eventType,
data: event.eventData,
metadata: event.metadata
})
);
await this.client.appendToStream(streamName, serializedEvents);
}
}Notice how we serialize events before storing them. This ensures they’re stored in a format that EventStore can efficiently handle.
Now let’s implement our first microservice. The user service handles user management and emits events for all changes:
// services/user-service/src/user.service.ts
@Injectable()
export class UserService {
constructor(private eventStore: EventStoreService) {}
async createUser(createUserDto: CreateUserDto): Promise<string> {
const userId = uuidv4();
const userCreatedEvent: UserCreatedEvent = {
id: uuidv4(),
aggregateId: userId,
aggregateVersion: 1,
eventType: 'UserCreated',
eventData: {
email: createUserDto.email,
firstName: createUserDto.firstName,
lastName: createUserDto.lastName
},
metadata: { timestamp: new Date() }
};
await this.eventStore.appendToStream(
`user-${userId}`,
[userCreatedEvent]
);
return userId;
}
}Every user action generates an event. But what happens when other services need to react to these events? That’s where Redis comes in.
We use Redis for publishing events between services. This creates loose coupling while maintaining reliability:
// shared/event-store/src/event-publisher.service.ts
@Injectable()
export class EventPublisherService {
private redis: Redis;
async publish(event: BaseEvent): Promise<void> {
await this.redis.publish(
'domain-events',
JSON.stringify(event)
);
}
}The order service subscribes to these events and maintains its own state:
// services/order-service/src/order.service.ts
@Injectable()
export class OrderService {
constructor(
private eventStore: EventStoreService,
private redis: Redis
) {
this.redis.subscribe('domain-events');
}
private async handleUserCreated(event: UserCreatedEvent) {
// Update read model or trigger other actions
await this.updateUserReadModel(event);
}
}This event-driven architecture allows each service to evolve independently. Have you thought about how you’ll handle schema evolution when events change over time?
Performance becomes crucial as event streams grow longer. That’s where snapshots help:
// services/user-service/src/user-snapshot.service.ts
@Injectable()
export class UserSnapshotService {
async createSnapshot(userId: string): Promise<void> {
const events = await this.loadEvents(userId);
const currentState = this.replayEvents(events);
await this.eventStore.appendToStream(
`snapshot-user-${userId}`,
[{
eventType: 'UserSnapshot',
eventData: currentState,
metadata: { timestamp: new Date() }
}]
);
}
}Snapshots let us rebuild state from intermediate points rather than replaying all events. This significantly improves read performance for frequently accessed aggregates.
Testing event-sourced systems requires a different approach. We need to verify both command handling and event emission:
// services/user-service/test/user.service.spec.ts
describe('UserService', () => {
it('should emit UserCreated event when creating user', async () => {
const userService = new UserService(eventStoreMock);
const userId = await userService.createUser(testUserDto);
expect(eventStoreMock.appendToStream).toHaveBeenCalledWith(
`user-${userId}`,
expect.arrayContaining([
expect.objectContaining({
eventType: 'UserCreated'
})
])
);
});
});Error handling deserves special attention. We implement retry mechanisms for event processing:
// services/order-service/src/event-handler.service.ts
@Injectable()
export class EventHandlerService {
async processWithRetry(
event: BaseEvent,
handler: Function,
maxRetries = 3
): Promise<void> {
for (let attempt = 1; attempt <= maxRetries; attempt++) {
try {
await handler(event);
break;
} catch (error) {
if (attempt === maxRetries) throw error;
await this.delay(Math.pow(2, attempt) * 1000);
}
}
}
}This retry logic with exponential backoff ensures our system can handle temporary failures gracefully.
Monitoring event flows is essential for production systems. We add structured logging to track event processing:
// shared/logging/src/event-logger.service.ts
@Injectable()
export class EventLoggerService {
private logger = new Logger('EventLogger');
logEventProcessing(event: BaseEvent, service: string) {
this.logger.log({
message: 'Event processed',
eventType: event.eventType,
aggregateId: event.aggregateId,
service,
timestamp: new Date().toISOString()
});
}
}As we scale, we might need to partition event streams or implement competing consumers. These patterns help distribute load across multiple service instances.
Building this system taught me valuable lessons about data consistency and system design. Event sourcing provides transparency that’s hard to achieve with traditional CRUD approaches. The complete history of changes becomes a feature rather than an afterthought.
I hope this guide helps you build more resilient and maintainable systems. If you found these insights valuable, I’d love to hear about your experiences. Please share this article with your team, and let me know in the comments what challenges you’ve faced with microservices architecture. Your feedback helps me create better content for our community.
