Over the years, I’ve seen too many Node.js applications crumble under the weight of unmanaged events. Loose typing, scattered listeners, and brittle integrations create maintenance nightmares. That’s why I’ve refined a robust approach combining TypeScript’s type safety with Redis’ distributed power. Let me show you how to build an event system that scales without sacrificing reliability.

Setting up our foundation starts with a clean TypeScript environment. We’ll install EventEmitter2 for advanced event features and Redis for cross-service communication. Here’s the core setup:

npm install eventemitter2 redis ioredis

// tsconfig.json
{
  "compilerOptions": {
    "target": "ES2020",
    "strict": true,
    "module": "commonjs"
  }
}

Type safety begins with rigorous event definitions. Notice how we enforce event structures and prevent invalid payloads:

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

interface UserCreatedEvent extends BaseEvent {
  type: 'user.created';
  data: {
    userId: string;
    email: string;
  };
}

type DomainEvent = UserCreatedEvent | OrderPlacedEvent;

Ever wondered what happens when your event schema changes? We solve this with versioned events and strict typing. Now let’s implement our event bus:

import EventEmitter2 from 'eventemitter2';

class EventBus {
  private emitter = new EventEmitter2();

  emit<T extends DomainEvent>(event: T): boolean {
    // Runtime validation example
    if (!event.id) throw new Error("Event ID missing");
    return this.emitter.emit(event.type, event);
  }

  on<T extends DomainEvent>(
    eventType: T['type'], 
    handler: (event: T) => void
  ): void {
    this.emitter.on(eventType, handler);
  }
}

This local emitter works great within a single process. But what about distributed systems? That’s where Redis enters the picture:

import Redis from 'ioredis';

const pub = new Redis();
const sub = new Redis();

// Subscribe to payment events
sub.subscribe('payment.processed', (err) => {
  if (err) console.error("Subscription failed", err);
});

sub.on('message', (channel, message) => {
  const event = JSON.parse(message) as DomainEvent;
  eventBus.emit(event);
});

// Publishing an event
pub.publish('order.placed', JSON.stringify(orderEvent));

Error handling becomes critical in distributed environments. Notice our dead-letter queue pattern:

eventBus.on('order.placed', async (event) => {
  try {
    await processOrder(event);
  } catch (error) {
    await storeInDeadLetterQueue(event, error);
  }
});

async function storeInDeadLetterQueue(event: DomainEvent, error: unknown) {
  const dlqEvent = { ...event, error: String(error) };
  await redis.rpush('dead_letter_queue', JSON.stringify(dlqEvent));
}

Testing event-driven systems requires special attention. Here’s how I verify event flows:

test('user.created triggers welcome email', async () => {
  const mockEmailService = { sendWelcome: jest.fn() };
  eventBus.on('user.created', mockEmailService.sendWelcome);

  await eventBus.emit({
    type: 'user.created',
    id: 'test-1',
    timestamp: new Date(),
    data: { userId: 'u1', email: '[email protected]' }
  });

  expect(mockEmailService.sendWelcome).toHaveBeenCalledTimes(1);
});

Performance monitoring is non-negotiable. We track event latency with Redis timestamps:

// Before processing
const start = Date.now();

// After processing
await redis.hset('event_metrics', event.id, 
  JSON.stringify({
    processingTime: Date.now() - start,
    status: 'processed'
  })
);

I’ve found these patterns prevent countless production issues. The type safety catches errors during development, while Redis provides the backbone for horizontal scaling. Your team can deploy new services that react to events without modifying existing codebases.

What challenges have you faced with event systems? Share your experiences below. If this approach resonates with you, spread the knowledge - like and share this with your network. Comments and questions are always welcome!