Pub/Sub

Prakash Bhattarai — Fri, 12 Jun 2026 07:43:33 +0000

Pub/Sub, also known as Publisher-Subscriber, is a communication model where services exchange messages through an intermediary service called a broker. The publisher publishes a message to a topic managed by the broker. Subscribers receive and consume messages from that topic without knowing anything about the producer of the message.

The core components of the Pub/Sub communication model are as follows:

Producers:

Producers create and publish messages to a topic. For example, in an e-commerce website, the producer may be the order service, which publishes order-related messages to the appropriate topic.

Subscribers:

Subscribers are services that receive and consume messages from a topic managed by the broker. They process messages without knowing anything about the producers of those messages. For example, in an e-commerce website, the payment service might be the consumer or subscriber that receives order messages and processes payments accordingly.

Broker:

The broker manages topics and handles the receiving and delivery of messages within those topics. The message itself contains the data sent by the producer, which is then used by the subscriber.

The advantages of the Pub/Sub mechanism are:

Reduced coupling: It reduces coupling between the producer and subscriber. The publisher does not need to have direct knowledge of the subscriber, and vice versa. This makes it easier to add new subscribers without changing the publisher itself.
Improved scalability: We can increase the number of subscribers when more messages are produced. If needed, we can also independently scale the producer.
Low-latency communication: With proper broker configuration, payload size, network conditions, and processing time, the system can support very low-latency message delivery.

The disadvantages are:

Increased complexity: With the introduction of a broker, there is a whole new system to manage alongside the producers and consumers. This adds another level of complexity to the system.
More difficult debugging: Since messages are produced and consumed independently, it becomes more difficult to trace the flow of messages.
Message ordering challenge: Depending on the broker and its configuration, messages may not always be processed in a strictly sequential order.

The common use cases of Pub/Sub are:

Real-time messaging and chat applications
Distributed systems and microservices
Event-driven architectures
Stream processing and pipelines
Notification and background processing

The common Pub/Sub brokers are:

Apache Kafka
Redis Pub/Sub
Google Cloud Pub/Sub

Example

Code snippets given below demonstrate the publisher which publishes count message to the topic messages managed by Redis every 200 ms and the subscribers which consumes message and prints count to the console.

// publisher.js
const Redis = require("ioredis");

const redis = new Redis();

async function run() {
  let i = 0;
  while (true) {
    redis.publish("messages", JSON.stringify({ count: i++ }));
    await new Promise((r) => setTimeout(r, 200));
  }
}

run().catch(console.error);

// subscriber.js
const Redis = require("ioredis");

const redis = new Redis();

async function run() {
  redis.subscribe("messages", (err) => err && console.log(err));
  redis.on("message", (channel, message) => {
    if (channel === "messages") {
      const parsed = JSON.parse(message);
      console.log(parsed.count);
    }
  });
}

run().catch(console.error);

References
https://docs.cloud.google.com/pubsub/docs/overview
https://redis.io/glossary/pub-sub/
https://www.youtube.com/watch?v=FMhbR_kQeHw

Scaling WebSocket

Prakash Bhattarai — Fri, 15 May 2026 05:08:41 +0000

WebSocket provides low-latency, bidirectional communication between clients and servers. It is a widely used solution for building real-time systems. Once a WebSocket connection is established, the underlying TCP connection remains open until either the client or the server closes it, allowing both sides to exchange messages continuously throughout the lifetime of the connection.

As systems grow, the challenge of scaling WebSocket infrastructure becomes important. Broadly, there are two approaches: vertical scaling and horizontal scaling.

In vertical scaling, the resources of a single server — CPU, RAM, and network bandwidth — are increased so it can handle more WebSocket connections. This approach works well for small to medium-scale systems, but only to a certain extent. A single machine cannot be scaled indefinitely, and relying on one server also introduces a single point of failure in systems where high availability is critical.

Horizontal scaling, on the other hand, increases the number of WebSocket servers. This approach improves redundancy and allows the system to scale using inexpensive commodity servers. However, horizontally scaling WebSocket servers introduces additional challenges.

To understand the problem, consider a multiplayer game with two WebSocket servers: A and B. Initially, players P1, P2, and P3 are connected to server A, and game events flow normally between them. Now suppose P1 disconnects and reconnects, but this time the load balancer routes P1 to server B instead of server A. How will P1 continue receiving events generated by P2 and P3?

It turns out, the problem can be solved using a shared message broker such as Redis Pub/Sub. When a WebSocket server receives an event, it publishes the event to Redis. Other WebSocket servers subscribed to the same channel receive the event and forward it to their connected clients. In this example, when P2 or P3 sends a game event to server A, server A publishes the event through Redis Pub/Sub. Server B then receives the event and forwards it to P1.

One important limitation of Redis Pub/Sub is that messages are not persisted. If Redis or a subscriber becomes temporarily unavailable, some events may be lost. Because of this, WebSocket systems are often designed so that occasional dropped events do not break the application. In systems where message loss is unacceptable, additional application-level mechanisms are used, such as acknowledgments, durable queues, event replay, and message persistence.

DEV Community: Prakash Bhattarai

Pub/Sub

Scaling WebSocket

References