[Redis Beyond Caching] Part 2: Real-time Pub/Sub with GraphQL Subscriptions

How to build a reactive architecture that pushes real-time updates to the frontend—combining GraphQL Subscriptions with Redis as the cross-server event bus.

🔄 The Evolution: From Polling to Push

The Polling Problem

Traditional web apps rely on client-side polling to fetch the latest state:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


Client                          Server
  │                               │
  │── GET /status ───────────────▶│
  │◀── { progress: 10% } ─────────│
  │         (wait 3 seconds)      │
  │── GET /status ───────────────▶│
  │◀── { progress: 10% } ─────────│  ← wasted request, no change
  │         (wait 3 seconds)      │
  │── GET /status ───────────────▶│
  │◀── { progress: 45% } ─────────│
  ...

Problems:

❌ Wasted server resources on unchanged data
❌ Latency gap between actual change and client awareness
❌ Doesn’t scale—10,000 clients = 10,000 requests every N seconds

The Push Model

Modern apps need server-initiated push—when backend state changes, the update is delivered to clients in milliseconds:

1
2
3
4
5
6
7
8


Client                          Server
  │                               │
  │── WebSocket handshake ───────▶│
  │◀── connection established ────│
  │                               │
  │  (server-side event occurs)   │
  │◀── { progress: 45% } ─────────│  ← instant push
  │◀── { progress: 100% } ────────│  ← instant push

🏗️ Architecture: GraphQL Subscriptions + Redis

Why GraphQL Subscriptions?

GraphQL has three operation types:

Query — Read data
Mutation — Write data
Subscription — Stream real-time updates over WebSocket

Subscriptions provide a standardized, type-safe way to push data to clients.

The Single-Server Limitation

A vanilla GraphQL server with subscriptions works fine on a single instance. But in production:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


┌─────────────────┐     ┌─────────────────┐
│   Pod A         │     │   Pod B         │
│   GraphQL       │     │   GraphQL       │
│   Server        │     │   Server        │
│   ┌───────────┐ │     │   ┌───────────┐ │
│   │In-Memory  │ │     │   │In-Memory  │ │
│   │PubSub     │ │     │   │PubSub     │ │
│   └───────────┘ │     │   └───────────┘ │
└────────┬────────┘     └────────┬────────┘
         │                       │
    User A connected        User B connected

Problem: If a Mutation runs on Pod B, User A (connected to Pod A) never receives the update. This is the “Island Effect”.

Redis as Cross-Server Event Bus

Redis Pub/Sub solves this by acting as a broadcast station that all pods listen to:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


┌─────────────────┐     ┌─────────────────┐
│   Pod A         │     │   Pod B         │
│   GraphQL       │     │   GraphQL       │
│   Server        │     │   Server        │
└────────┬────────┘     └────────┬────────┘
         │                       │
         │   subscribe           │   subscribe
         ▼                       ▼
┌─────────────────────────────────────────┐
│              Redis Pub/Sub              │
│                                         │
│  Channel: "TASK_UPDATED"                │
│  Channel: "NOTIFICATION"                │
└─────────────────────────────────────────┘
         ▲
         │ publish
         │
┌────────┴────────┐
│     Worker      │
│  (any pod)      │
└─────────────────┘

Now when any service publishes to Redis, all pods receive the message and push to their connected clients.

⚠️ Limitation: This is best-effort fan-out for currently online clients only. No backpressure, no persistence, no replay.

💻 Implementation

Setup: graphql-redis-subscriptions

1
2
3
4
5
6
7


import { RedisPubSub } from 'graphql-redis-subscriptions';
import Redis from 'ioredis';

const pubsub = new RedisPubSub({
  publisher: new Redis({ host: 'redis' }),
  subscriber: new Redis({ host: 'redis' }),
});

Publisher: Any Backend Service

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


// Worker, API, Cron Job — anyone can publish
async function onTaskComplete(taskId: string, result: any) {
  await pubsub.publish('TASK_UPDATED', {
    taskUpdated: {
      id: taskId,
      status: 'completed',
      result,
    },
  });
}

Subscriber: GraphQL Resolver

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24


// GraphQL Schema
const typeDefs = `
  type Task {
    id: ID!
    status: String!
    result: JSON
  }

  type Subscription {
    taskUpdated(taskId: ID!): Task
  }
`;

// Resolver
const resolvers = {
  Subscription: {
    taskUpdated: {
      subscribe: withFilter(
        () => pubsub.asyncIterator('TASK_UPDATED'),
        (payload, variables) => payload.taskUpdated.id === variables.taskId
      ),
    },
  },
};

Client: Apollo Client

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


import { useSubscription, gql } from '@apollo/client';

const TASK_SUBSCRIPTION = gql`
  subscription OnTaskUpdated($taskId: ID!) {
    taskUpdated(taskId: $taskId) {
      id
      status
      result
    }
  }
`;

function TaskProgress({ taskId }) {
  const { data, loading } = useSubscription(TASK_SUBSCRIPTION, {
    variables: { taskId },
  });

  if (loading) return <Spinner />;
  return <ProgressBar value={data?.taskUpdated?.progress} />;
}

⚠️ Production Caveats

Redis Pub/Sub is Fire-and-Forget

Feature	Redis Pub/Sub	Redis Stream
Message Persistence	❌ No	✅ Yes
Replay on Reconnect	❌ No	✅ Yes
Acknowledgment	❌ No	✅ Yes
Delivery Guarantee	At-most-once	At-least-once

👉 If a subscriber disconnects, messages are lost. Pub/Sub is suitable for:

UI updates where missing one is tolerable
Signals that trigger a re-fetch
Non-critical notifications

For critical messaging, consider Redis Streams or a dedicated message broker (Kafka, RabbitMQ).

WebSocket Connection Management

Connection limits — Each pod can only handle so many WebSocket connections
Sticky sessions — Required only if subscription state is kept in-memory without a shared pub/sub layer. With Redis Pub/Sub, sticky sessions are optional.
Heartbeat/ping — Detect stale connections and clean up

Filtering at Scale

The example above broadcasts to all subscribers. In production:

1
2
3
4


subscribe: withFilter(
  () => pubsub.asyncIterator('TASK_UPDATED'),
  (payload, variables) => payload.taskUpdated.id === variables.taskId
)

Use withFilter to ensure clients only receive events they care about—otherwise you’re wasting bandwidth.

Advanced: MQ + Pub/Sub Separation

In high-reliability systems, you may add a message queue between internal services and Redis Pub/Sub:

1
2
3
4


┌──────────────┐     ┌──────────────────┐     ┌──────────────────┐     ┌─────────┐
│   Worker     │────▶│   Message Queue  │────▶│  GraphQL Server  │────▶│ Clients │
│              │     │   (RabbitMQ)     │     │  (Redis Pub/Sub) │     │         │
└──────────────┘     └──────────────────┘     └──────────────────┘     └─────────┘

Why this pattern?

MQ provides message persistence—if the GraphQL server is restarting, messages wait in queue
Separates internal service communication (reliable) from client broadcasting (best-effort)
Easier to scale each layer independently

📝 Summary

Polling → Push — Eliminates wasted requests, provides instant UI updates
Redis as Event Bus — Solves the “Island Effect” in multi-pod deployments
GraphQL Subscriptions — Standardized, type-safe real-time API
Trade-off — Pub/Sub is fire-and-forget; use Streams for durability

With Redis as the only additional infrastructure component, you get horizontally scalable real-time capabilities.