I’ve been building web applications for years, and one challenge that always stood out was creating a notification system that’s both real-time and scalable. Recently, I worked on a project where users needed instant updates across multiple devices, and traditional polling just wasn’t cutting it. That’s when I decided to build a robust system using Node.js, Redis, and Server-Sent Events. Why did I choose this stack? Because it combines the event-driven nature of Node.js with Redis’s pub/sub capabilities and SSE’s simplicity for browser communication.

Let me walk you through how I built this system. We’ll start with the core architecture. Imagine you have multiple Node.js instances running behind a load balancer. How do you ensure that a notification sent from one server reaches all connected clients, regardless of which server they’re connected to? That’s where Redis comes in. It acts as a central message bus, allowing all servers to communicate seamlessly.

Here’s a basic setup for the event bus in TypeScript:

class EventBus {
  private events: Map<string, Function[]> = new Map();

  on(event: string, callback: Function) {
    if (!this.events.has(event)) {
      this.events.set(event, []);
    }
    this.events.get(event)!.push(callback);
  }

  emit(event: string, data: any) {
    const callbacks = this.events.get(event);
    if (callbacks) {
      callbacks.forEach(callback => callback(data));
    }
  }
}

But wait, how do we handle thousands of concurrent connections without crashing the server? That’s a question I often get. The key is to use non-blocking I/O and manage connections efficiently. In Node.js, we can leverage its event loop to handle multiple requests simultaneously.

Now, let’s integrate Redis for pub/sub. Redis allows us to publish messages from one server and subscribe to them on others. This is crucial for horizontal scaling.

import Redis from 'ioredis';

const redis = new Redis(process.env.REDIS_URL);

// Subscribe to a channel
redis.subscribe('notifications', (err, count) => {
  if (err) console.error('Subscription failed');
  else console.log(`Subscribed to ${count} channels`);
});

// Publish a message
redis.publish('notifications', JSON.stringify({
  userId: '123',
  message: 'New alert!'
}));

When a user connects, we establish an SSE connection. Server-Sent Events are perfect for notifications because they’re simple, work over HTTP, and automatically reconnect if dropped. Have you ever wondered why SSE might be better than WebSockets for some use cases? It’s because SSE is unidirectional, which fits perfectly for sending updates from server to client without the overhead of bidirectional communication.

Here’s how I set up the SSE endpoint in Express:

app.get('/sse', (req, res) => {
  res.writeHead(200, {
    'Content-Type': 'text/event-stream',
    'Cache-Control': 'no-cache',
    'Connection': 'keep-alive'
  });

  const userId = getUserIdFromRequest(req); // Assume this extracts user ID
  const connectionId = uuidv4();

  // Store the connection
  connections.set(connectionId, { res, userId });

  req.on('close', () => {
    connections.delete(connectionId);
  });
});

But what about security? We need to ensure that users only receive their own notifications. I added authentication middleware to verify tokens before establishing SSE connections. This prevents unauthorized access and keeps data isolated.

For the notification service, I defined clear types to maintain consistency:

interface Notification {
  id: string;
  userId: string;
  title: string;
  message: string;
  priority: 'low' | 'medium' | 'high';
  createdAt: Date;
}

Performance optimization was critical. I implemented connection pooling for Redis and used clustering in Node.js to utilize multiple CPU cores. Also, I made sure to handle errors gracefully—like network timeouts or Redis failures—so the system degrades smoothly without crashing.

Deploying to production involved setting up monitoring with tools like PM2 and logging with Winston. I configured health checks to ensure the system remains responsive under load.

Throughout this process, I learned that simplicity often beats complexity. While there are alternatives like WebSockets or third-party services, building a custom solution gave me full control and cost savings. What would you do differently in your notification system?

I hope this guide helps you build your own high-performance notification system. If you found it useful, please like, share, and comment with your experiences or questions. Let’s keep the conversation going!