Building a real-time notification system with zero external dependencies

Our clients needed to see payment status updates in real time. Not refresh-the-page real time. Actually real time, where the dashboard updates within a second of a payment state change. The obvious solutions were Redis pub/sub, a managed WebSocket service like Pusher, or a message queue like RabbitMQ. Every one of those adds infrastructure, cost, and operational complexity to a system that was already doing everything it needed with PostgreSQL and Node.js. I refused to add a dependency for a single feature.

In that first stretch at FinanceOps, I was still learning how to wear the Head of Engineering title without hiding behind it. It also builds on what I learned earlier in “Node.js 22 dropped and here is what actually matters for production backends.” The only credibility that mattered was whether the decision survived contact with real money, ugly edge cases, and the next person I would eventually hire. That same bias toward strict boundaries later shaped how I approached ftryos and pipeline-sdk: make correctness boring before you make the API clever.

The Architecture: SSE Plus LISTEN/NOTIFY

The system has two parts. PostgreSQL LISTEN/NOTIFY channels push events from the database to the Node.js process when payment rows change. Server-Sent Events push those events from Node.js to connected browser clients. The entire implementation is about 200 lines of code with no external dependencies beyond what we already had.

1
-- Trigger that fires on payment status changes
2
CREATE OR REPLACE FUNCTION notify_payment_update()
3
RETURNS TRIGGER AS $$
4
BEGIN
5
  PERFORM pg_notify(
6
    'payment_updates',
7
    json_build_object(
8
      'paymentId', NEW.id,
9
      'tenantId', NEW.tenant_id,
10
      'status', NEW.status,
11
      'updatedAt', NEW.updated_at
12
    )::text
13
  );
14
  RETURN NEW;
15
END;
16
$$ LANGUAGE plpgsql;
17

18
CREATE TRIGGER payment_status_change
19
  AFTER UPDATE OF status ON payments
20
  FOR EACH ROW
21
  WHEN (OLD.status IS DISTINCT FROM NEW.status)
22
  EXECUTE FUNCTION notify_payment_update();

The trigger fires only when the status column actually changes, not on every update. This keeps the notification volume manageable. At our peak, we process about 200 payment status changes per minute. LISTEN/NOTIFY handles this without breaking a sweat.

The Node.js Listener

On the Node.js side, a single persistent database connection listens for notifications and fans them out to connected SSE clients. The connection is separate from the application connection pool because LISTEN requires an idle connection that is not being used for queries.

1
import { Client } from 'pg';
2

3
const listener = new Client({ connectionString: DATABASE_URL });
4
await listener.connect();
5
await listener.query('LISTEN payment_updates');
6

7
// Map of tenantId -> Set of SSE response objects
8
const clients = new Map<string, Set<Response>>();
9

10
listener.on('notification', (msg) => {
11
  if (!msg.payload) return;
12
  const event = JSON.parse(msg.payload);
13
  const tenantClients = clients.get(event.tenantId);
14
  if (!tenantClients) return;
15

16
  for (const res of tenantClients) {
17
    res.write(`data: ${msg.payload}\n\n`);
18
  }
19
});

The fan-out is tenant-scoped. Each SSE connection registers with its tenant ID, and events are only sent to clients belonging to the same tenant. This is critical for multi-tenant isolation. A payment update for Tenant A must never reach a browser session for Tenant B.

The SSE Endpoint

The client connects to a standard SSE endpoint. The browser EventSource API handles reconnection automatically, which is one of the biggest advantages over raw WebSockets for this use case.

1
// Next.js Route Handler for SSE
2
export async function GET(req: Request) {
3
  const tenantId = await getTenantFromSession(req);
4
  const stream = new ReadableStream({
5
    start(controller) {
6
      const encoder = new TextEncoder();
7
      const send = (data: string) => {
8
        controller.enqueue(
9
          encoder.encode(`data: ${data}\n\n`)
10
        );
11
      };
12
      // Register this client
13
      registerClient(tenantId, send);
14
      // Send heartbeat every 30s to keep connection alive
15
      const heartbeat = setInterval(() => {
16
        send(JSON.stringify({ type: 'heartbeat' }));
17
      }, 30000);
18
      // Cleanup on disconnect
19
      req.signal.addEventListener('abort', () => {
20
        clearInterval(heartbeat);
21
        removeClient(tenantId, send);
22
      });
23
    },
24
  });
25
  return new Response(stream, {
26
    headers: {
27
      'Content-Type': 'text/event-stream',
28
      'Cache-Control': 'no-cache',
29
      Connection: 'keep-alive',
30
    },
31
  });
32
}

The 30-second heartbeat is essential. Without it, load balancers and proxies will close idle connections. The heartbeat keeps the connection alive and also serves as a health check. If a client stops receiving heartbeats, it knows the connection is dead and EventSource automatically reconnects.

Tradeoffs and Limits

• Single-process fan-out: This architecture assumes one Node.js process handles all SSE connections. Once we scale beyond a single process, we need a shared pub/sub layer between instances. That is when Redis enters the picture.
• LISTEN/NOTIFY has no persistence: If the Node.js process is down when a notification fires, the event is lost. We mitigate this with a catch-up query on SSE reconnection that fetches payments updated in the last 60 seconds.
• Connection limits: Each SSE client holds an open HTTP connection. At 500 concurrent clients, this is fine. At 5,000, we would need to consider WebSocket multiplexing or a dedicated push service.
• No binary data: SSE is text-only. For our JSON payloads this is not a limitation, but it rules out streaming binary data.

We ran this architecture in production for eight months before hitting the scaling limit. The signal was clear: when we added a second Node.js process behind the load balancer, clients connected to process A stopped receiving events published by process B. That was the point where we added Redis pub/sub as a cross-process channel. But those eight months of zero-dependency real-time notifications served us well.

The builder phase was less glamorous than people imagine. It was mostly a series of stubborn, unfashionable choices that kept future-me out of 2 a.m. incident calls. I still make the same kind of choices inside portfolio, pipeline-sdk, and dotfiles.

Do not add infrastructure because a tutorial told you to. Add it when your current solution stops working and you understand exactly why.

The zero-dependency approach worked because the problem was simpler than we initially assumed. Most real-time notification systems do not need message persistence, guaranteed delivery, or complex routing. They need a reliable connection, a clean message format, and graceful reconnection logic. By building on native platform capabilities instead of reaching for a library, we ended up with a system that was easier to debug, cheaper to operate, and faster to extend when new notification types appeared.