Publish–Subscribe in NATS: Simple and Powerful Messaging

Pub/Sub vs JetStream

The most important thing to understand is that basic pub/sub in NATS is ephemeral, while JetStream adds persistence and replay.

Basic Pub/Sub

• Messages are delivered only to subscribers that are online at the moment.
• If no subscriber is connected, the message is lost forever.
• There is no way to replay past messages.

Example use case:

• A live chat application where users in a room subscribe to chat.room1.
• Messages are delivered instantly to everyone online.
• If a user is offline, they never see the message.

JetStream Pub/Sub

• Messages are stored in a stream (on disk or memory).
• Consumers can be durable, meaning they remember their position in the stream.
• You can replay past messages, even if you were offline when they were first published.

Example use case:

• An e-commerce order system with events like orders.created and orders.paid.
• A shipping service might go offline for maintenance. With JetStream, when it comes back, it can continue processing from the exact point it left off.
• Auditors can also replay old events to analyze the order lifecycle.

Pub/Sub vs Request–Reply

NATS also supports a Request–Reply pattern, where a client sends a message and expects a response. But pub/sub is different:

• Messages are broadcast to all subscribers.
• There is no direct reply.
• It’s one-to-many communication.

Limitations of Basic Pub/Sub

• If no subscriber is online, messages are lost (unless you use JetStream for persistence).
• Subscribers get messages in real time only.

This is why JetStream was introduced — to add persistence and replay on top of pub/sub.

Final Thoughts

Publish–Subscribe is the foundation of NATS. It’s simple but powerful, allowing you to build decoupled systems that can scale. By combining subjects with wildcards, you can design flexible messaging patterns for almost any scenario.