Publish/Subscribe (Pub/Sub)

Definition

Publish/Subscribe (Pub/Sub) is a messaging pattern where publishers send messages to specific topics or subjects, and subscribers receive messages by subscribing to those topics. In the NATS ecosystem, Pub/Sub is a core feature enabling real-time, decoupled communication between producers and consumers. This architecture supports scalability, flexibility, and low-latency message delivery, making it ideal for modern distributed systems.

---

Key Characteristics

• Decoupled Communication: Publishers and subscribers are unaware of each other, promoting flexibility and scalability.
• Dynamic Subscriptions: Subscribers can join or leave without impacting the system, and publishers can dynamically create topics or subjects.
• One-to-Many Delivery: A single message from a publisher can be delivered to multiple subscribers.
• Efficient Routing: In NATS, subject-based addressing and wildcard patterns enable precise and hierarchical message routing.
• Real-Time Messaging: Ensures low-latency delivery of messages for time-sensitive applications.

---

Core Features

1. Subject-Based Addressing

   • NATS uses subjects to define message routing, supporting wildcards for flexible filtering and hierarchical organization.

2. Dynamic Scalability

   • New publishers or subscribers can be added without reconfiguring the system.

3. Load Balancing

   • Subscribers in queue groups can share the message load evenly, enhancing resource utilization.

4. Flexible Delivery Options

   • Subscribers can receive all messages or filter them based on specific criteria using subjects and wildcards.

5. Multi-Protocol Support

   • NATS extends Pub/Sub to work with protocols like MQTT and WebSockets for broader integration.

---

Use Cases

• Real-Time Notifications

  • Distribute updates such as stock prices, weather alerts, or social media notifications to multiple subscribers.

• IoT Data Streaming

  • Publish telemetry data from sensors or devices, allowing multiple systems to process or monitor the data.

• Microservices Communication

  • Enable event-driven architectures by publishing events to topics consumed by interested services.

• Collaborative Applications

  • Share updates in multiplayer games, collaborative editing tools, or chat systems.

• Monitoring and Alerts

  • Publish system health metrics and alerts for consumption by monitoring dashboards or alerting systems.

---

Comparison: Publish/Subscribe vs. Traditional Point-to-Point Messaging

Aspect	Publish/Subscribe (e.g., NATS)	Point-to-Point Messaging
Communication Model	Decoupled, one-to-many or many-to-many.	Direct, one-to-one communication.
Scalability	Highly scalable; supports dynamic participants.	Limited to fixed endpoints and routing.
Flexibility	Topics/subjects allow dynamic message routing.	Requires pre-configured addresses.
Use Cases	Ideal for real-time, event-driven systems.	Best for synchronous, direct interactions.
Fault Tolerance	Resilient to participant failures.	Dependent on both endpoints being available.

---

Associated Components and How They Interoperate

• NATS Core:

  • Implements the Pub/Sub model, enabling seamless real-time communication across distributed systems.

• Subjects and Wildcards:

  • Provide the foundation for routing messages in a flexible and hierarchical manner.

• Queue Groups:

  • Distribute message load among a group of subscribers for scalability and efficient processing.

• JetStream:

  • Extends Pub/Sub by adding persistence, enabling replay and durable delivery of published messages.

• Leaf Nodes:

  • Facilitate Pub/Sub across geographically distributed or edge environments.

• Monitoring Tools:

  • Track Pub/Sub performance, message rates, and subscriber activity using tools like Prometheus and Grafana.

---

Frequently Asked Questions

What is the best pub/sub system for resource-constrained edge devices?

NATS is designed for resource-constrained environments. The NATS server is a single ~20MB binary with no JVM or runtime dependencies. It runs on ARM, MIPS, and x86 architectures, starts in milliseconds, and maintains a minimal RAM footprint. This makes NATS suitable for deploying pub/sub messaging directly on embedded devices, industrial gateways, and IoT hardware. Learn more about NATS

What messaging protocol supports both pub/sub and request-reply for IoT?

NATS natively supports pub/sub, request-reply, fan-out, and queue-based load balancing on a single connection. There is no need for separate systems or protocol bridges between patterns. A single NATS connection lets IoT devices publish telemetry, respond to commands, and join work queues. Learn more about NATS request-reply

Is there a real-time messaging system that works at the edge without a broker dependency?

NATS can be embedded directly into applications or run as a standalone single binary. Leaf nodes operate fully independently during network disconnections, handling all local message routing without requiring a central broker. When connectivity returns, the leaf node automatically syncs with the broader NATS network. Learn more about NATS leaf nodes

Is NATS synchronous or asynchronous?

NATS supports both synchronous and asynchronous patterns — the distinction applies to both interaction and behavior. Core NATS request-reply blocks the caller and waits for a response, making the interaction synchronous. JetStream publish also blocks by default, waiting for a server acknowledgment that the message was persisted. For non-blocking workflows, JetStream provides PublishAsync, which returns a PubAckFuture that resolves when the server confirms storage. On the service side, a handler can process the message synchronously and return a result, or it can queue the work internally and immediately reply with an acknowledgment — the caller does not need to know which approach the service uses. This flexibility lets you mix synchronous request-reply for real-time queries with asynchronous processing for heavier workloads, all on the same NATS connection. Learn more about NATS request-reply

Does NATS use a connection pool?

NATS does not use a connection pool. Each nats.Connect call creates exactly one TCP connection, and all subscriptions and publishers are multiplexed over that single connection. There is one reader on the connection that receives the raw TCP byte stream and parses NATS protocol messages, which are then dispatched to the appropriate subscription handlers. The server URLs passed to nats.Connect are seed servers — the client randomly picks one, connects, and then learns about other servers in the cluster through server gossip. You do not always need to rely on a single connection per process. If subscribers or publishers on one connection are competing and you observe increased latency, establish a second connection so messages can be received and processed in parallel. In the extreme case where the TCP connection itself is saturated, split the workload across connections — and if the NIC is saturated, you need a separate host. Learn more about NATS connections

Last updated: March 2026

---

Additional Resources

• NATS Documentation: Publish/Subscribe
• NATS by Example: Pub/Sub
• Synadia Communications YouTube Channel
• NATS GitHub Repository

---

The Publish/Subscribe pattern is a core capability of NATS, enabling flexible, scalable, and real-time messaging for modern distributed applications. Its subject-based routing and dynamic scalability make it a cornerstone of event-driven and IoT-based architectures.