I’ve been thinking a lot lately about how we build resilient, scalable systems that don’t sacrifice developer experience. The challenge of maintaining type safety across distributed components while ensuring reliable message processing led me to explore combining TypeScript, NestJS, and Redis Streams. Let me share what I’ve learned.

Why does type safety matter in event-driven systems? When you’re dealing with events flowing between services, a small type mismatch can cascade into production issues. TypeScript gives us compile-time validation, while Redis Streams provides persistence and ordering guarantees.

Here’s how I approach creating type-safe events. First, define a base interface that all events will implement:

interface BaseEvent {
  id: string;
  eventType: string;
  timestamp: Date;
  aggregateId: string;
}

interface DomainEvent<T> extends BaseEvent {
  payload: T;
}

Now let’s create a concrete event. Notice how we’re using TypeScript’s type system to ensure payload validity:

class UserCreatedEvent implements DomainEvent<UserCreatedPayload> {
  id: string;
  eventType = 'user.created';
  timestamp: Date;
  aggregateId: string;
  
  constructor(public payload: UserCreatedPayload) {
    this.id = uuid();
    this.timestamp = new Date();
    this.aggregateId = payload.userId;
  }
}

But how do we ensure these events are properly validated before they hit the stream? I use class-validator decorators on the payload:

class UserCreatedPayload {
  @IsUUID()
  userId: string;

  @IsEmail()
  email: string;

  @IsString()
  firstName: string;

  @IsString()
  lastName: string;
}

Setting up Redis Streams integration in NestJS is straightforward. Here’s a basic service that handles stream operations:

@Injectable()
export class EventStreamService {
  private readonly redis: Redis;

  constructor() {
    this.redis = new Redis(process.env.REDIS_URL);
  }

  async publishEvent(stream: string, event: BaseEvent) {
    await this.redis.xadd(stream, '*', 
      'event', JSON.stringify(event)
    );
  }
}

What happens when you need to process events reliably? Consumer groups are your answer. They allow multiple consumers to work on the same stream while maintaining processing guarantees:

async createConsumerGroup(stream: string, group: string) {
  try {
    await this.redis.xgroup('CREATE', stream, group, '0');
  } catch (error) {
    if (error.message !== 'BUSYGROUP Consumer Group name already exists') {
      throw error;
    }
  }
}

Error handling is crucial in production systems. Here’s how I implement dead letter queues for failed events:

async handleFailedEvent(originalEvent: BaseEvent, error: Error) {
  const deadLetterEvent = {
    ...originalEvent,
    originalTimestamp: originalEvent.timestamp,
    error: error.message,
    retryCount: (originalEvent.retryCount || 0) + 1
  };
  
  await this.redis.xadd('dead-letter-stream', '*',
    'event', JSON.stringify(deadLetterEvent)
  );
}

Monitoring event flows becomes essential as your system grows. I add metadata to events for better observability:

interface BaseEvent {
  // ... existing fields
  correlationId?: string;
  sourceService: string;
  metadata?: {
    traceId?: string;
    spanId?: string;
  };
}

Have you considered how event ordering affects your business logic? Redis Streams maintains insertion order, but sometimes you need to handle out-of-order events gracefully. I use version numbers in aggregate events:

interface BaseEvent {
  // ... existing fields
  version: number;
  previousVersion?: number;
}

Testing event-driven systems requires a different approach. I create in-memory test streams and verify event contents:

describe('User Events', () => {
  it('should publish user.created event with correct payload', async () => {
    const event = new UserCreatedEvent(testPayload);
    await eventService.publishEvent('users', event);
    
    const events = await testRedis.xrange('users', '-', '+');
    const publishedEvent = JSON.parse(events[0][1][1]);
    
    expect(publishedEvent.payload.email).toEqual(testPayload.email);
  });
});

Building this architecture has transformed how I think about distributed systems. The combination of TypeScript’s type safety, NestJS’s structure, and Redis Streams’ reliability creates a foundation that scales while remaining maintainable.

What challenges have you faced with event-driven architectures? I’d love to hear your experiences and thoughts. If you found this helpful, please share it with others who might benefit, and feel free to leave comments or questions below.