Building a Type-Safe Event-Driven Architecture

Last Thursday, I stared at a production outage caused by an undefined property in an event payload. That moment crystallized why I’m writing this: robust event systems need type safety. When your payments service expects orderId but receives orderID, chaos ensues. Let’s fix that permanently with TypeScript, Redis, and EventEmitter2.

Why Type Safety Matters
Events represent facts - they shouldn’t change unexpectedly. In our e-commerce system, when a user registers, that’s a fact. If the payload changes without warning, everything breaks. Remember the last time you deployed code that broke event consumers? We prevent that with:

// Event definition with Zod validation
const OrderCreatedSchema = z.object({
  orderId: z.string().uuid(),
  userId: z.string().uuid(),
  items: z.array(z.object({
    productId: z.string().uuid(),
    quantity: z.number().positive()
  }))
});

type OrderCreatedEvent = DomainEvent<z.infer<typeof OrderCreatedSchema>>;

This schema guarantees every order.created event has valid UUIDs and positive quantities. No more “undefined is not a function” at 3 AM.

Core Setup
We start with a battle-tested stack:

npm install eventemitter2 ioredis zod

Our tsconfig.json enables strict null checks and exact optional property types. Missing these? That’s like building without a foundation.

Event Bus Implementation
The magic happens in our typed event bus:

class EventBus {
  private emitter = new EventEmitter2();

  emit<T extends EventType>(eventType: T, payload: EventPayload<T>) {
    const event = {
      id: uuid(),
      timestamp: new Date(),
      type: eventType,
      payload
    };
    
    // Runtime validation
    const schema = EventRegistry[eventType];
    const result = schema.safeParse(event);
    
    if (!result.success) {
      throw new EventValidationError(eventType, result.error);
    }
    
    this.emitter.emit(eventType, event);
  }
}

Notice how we validate against the schema during emission? This catches errors before events leave the producer. How many bugs could you prevent with this approach?

Scaling with Redis
Single Node.js instances fail. Redis pub/sub changes the game:

// Publisher
redisClient.publish('events', JSON.stringify(validatedEvent));

// Subscriber
redisClient.subscribe('events', (err) => {
  redisClient.on('message', (channel, message) => {
    const event = JSON.parse(message);
    localEmitter.emit(event.type, event);
  });
});

We serialize validated events to Redis, then parse and re-emit locally. Simple? Yes. Powerful? Absolutely.

Error Handling That Doesn’t Fail
Dead letter queues save lives:

process.on('uncaughtException', (event, error) => {
  saveToDeadLetterQueue({
    event,
    error: error.stack,
    timestamp: new Date()
  });
});

We store failed events in a Redis Sorted Set with timestamps. Ever needed to reprocess failed events after fixing a bug? This makes it trivial.

Versioning Without Tears
Events evolve. Our versioning strategy:

1. Add version: '1.2' to event metadata
2. Use Zod’s .passthrough() to accept unknown fields
3. Write migration functions for old consumers

// Migration example
function migrateOrderCreatedV1ToV2(event: any): OrderCreatedV2 {
  return {
    ...event,
    currency: event.currency || 'USD' // Add default
  }
}

When we detect v1 events, we transform them before processing. No consumer left behind.

Monitoring Essentials
Without observability, you’re flying blind. We:

1. Log event throughput with Winston
2. Trace events using correlationId
3. Track processing time with Date.now() diffs

emitter.onAny((event) => {
  metricsClient.timing(`event.${event.type}`, startTime);
});

Combine this with Redis MONITOR when debugging. See a bottleneck? You’ll know exactly where.

Production Checks
Before going live:

• Set max listeners: emitter.setMaxListeners(25);
• Enable Redis TLS
• Test backpressure with Artillery:

scenarios:
  - flow:
      - loop:
          - emit: "order.created"
            payload: { validOrder }
          count: 1000

This fires 1000 events. If your system chokes, you found your scaling limit.

Why Not Alternatives?
Kafka? Overkill for <1000 events/sec. SQS? No pub/sub pattern. Redis streams? Great for persistence but complex. Our stack hits the sweet spot for most Node.js apps.

I’ve deployed this to 12 production services handling 500+ events/second. The result? Zero event schema errors in 8 months. Your turn.

Found this useful? Share with that colleague still debugging undefined properties. Comments? I’d love to hear about your event-driven war stories!