NATS compared to Azure ServiceBus

[mariomuja]

We are not sure, whether we shall use NATS or Azure ServiceBus.
Microsoft lists the following advanced features for ServiceBus.
Can you please tell us, whether NATS supports the same features?

1. When should I use Azure ServiceBus instead of NATS?

2. When should I use NATS instead of Azure ServiceBus?

3. "NATS is a fire-and-forget messaging system. If you need higher levels of service, you can use NATS Streaming or build additional reliability into your client"

Does that mean that NATS does NOT provide the level of reliability that Azure ServiceBus provides (like transactions and other features listed below) ?

Thanks a lot for your help,
Mario

---- Features listed by Microsoft for Azure ServiceBus ----
Message sessions
To create a first-in, first-out (FIFO) guarantee in Service Bus, use sessions. Message sessions enable joint and ordered handling of unbounded sequences of related messages. For more information, see Message sessions: first in, first out (FIFO).

Autoforwarding
The autoforwarding feature chains a queue or subscription to another queue or topic. They must be part of the same namespace. With autoforwarding, Service Bus automatically removes messages from a queue or subscription and puts them in a different queue or topic. For more information, see Chaining Service Bus entities with autoforwarding.

Dead-letter queue
Service Bus supports a dead-letter queue (DLQ). A DLQ holds messages that can't be delivered to any receiver. It holds messages that can't be processed. Service Bus lets you remove messages from the DLQ and inspect them. For more information, see Overview of Service Bus dead-letter queues.

Scheduled delivery
You can submit messages to a queue or topic for delayed processing. You can schedule a job to become available for processing by a system at a certain time. For more information, see Scheduled messages.

Message deferral
A queue or subscription client can defer retrieval of a message until a later time. This deferral might be because of special circumstances in the application. The message remains in the queue or subscription, but it's set aside. For more information, see Message deferral.

Batching
Client-side batching enables a queue or topic client to delay sending a message for a certain period of time. If the client sends additional messages during this time period, it transmits the messages in a single batch. For more information, see Client-side batching.

Transactions
A transaction groups two or more operations together into an execution scope. Service Bus supports grouping operations against a single messaging entity within the scope of a single transaction. A message entity can be a queue, topic, or subscription. For more information, see Overview of Service Bus transaction processing.

Filtering and actions
Subscribers can define which messages they want to receive from a topic. These messages are specified in the form of one or more named subscription rules. For each matching rule condition, the subscription produces a copy of the message, which can be differently annotated for each matching rule. For more information, see Topic filters and actions.

Autodelete on idle
Autodelete on idle enables you to specify an idle interval after which a queue is automatically deleted. The minimum duration is 5 minutes. For more information, see the QueueDescription.AutoDeleteOnIdle Property.

Duplicate detection
An error could cause the client to have a doubt about the outcome of a send operation. Duplicate detection enables the sender to resend the same message. Another option is for the queue or topic to discard any duplicate copies. For more information, see Duplicate detection.

Security protocols

Service Bus supports security protocols such as Shared Access Signatures (SAS), Role Based Access Control (RBAC) and Managed identities for Azure resources.

[derekcollison]

NATS has release in tech preview our new technology called JetStream. It provides persistence and at least once semantics. We do not provide all of the features above, but here is a link to get you started.

https://github.com/nats-io/jetstream/blob/master/README.md

Here is some commentary on how we compare.

Message sessions
To create a first-in, first-out (FIFO) guarantee in Service Bus, use sessions. Message sessions enable joint and ordered handling of unbounded sequences of related messages. For more information, see Message sessions: first in, first out (FIFO).

The JetStream system creates a globally ordered stream which accomplishes this by default.

Autoforwarding
The autoforwarding feature chains a queue or subscription to another queue or topic. They must be part of the same namespace. With autoforwarding, Service Bus automatically removes messages from a queue or subscription and puts them in a different queue or topic. For more information, see Chaining Service Bus entities with autoforwarding.

We do not support this feature but can easily be accomplished within an application

Dead-letter queue
Service Bus supports a dead-letter queue (DLQ). A DLQ holds messages that can't be delivered to any receiver. It holds messages that can't be processed. Service Bus lets you remove messages from the DLQ and inspect them. For more information, see Overview of Service Bus dead-letter queues.

We have support for this concept

Scheduled delivery
You can submit messages to a queue or topic for delayed processing. You can schedule a job to become available for processing by a system at a certain time. For more information, see Scheduled messages.

We currently do not support this

Message deferral
A queue or subscription client can defer retrieval of a message until a later time. This deferral might be because of special circumstances in the application. The message remains in the queue or subscription, but it's set aside. For more information, see Message deferral.

We currently do not support this

Batching
Client-side batching enables a queue or topic client to delay sending a message for a certain period of time. If the client sends additional messages during this time period, it transmits the messages in a single batch. For more information, see Client-side batching.

We currently do not support this, NATS is extremely performant and JetStream in early tests shows excellent performance as well for a persistent system, so no need at the moment

Transactions
A transaction groups two or more operations together into an execution scope. Service Bus supports grouping operations against a single messaging entity within the scope of a single transaction. A message entity can be a queue, topic, or subscription. For more information, see Overview of Service Bus transaction processing.

We currently do not support this, but have been considering this or atomic operations for common use cases like replying to a request

Filtering and actions
Subscribers can define which messages they want to receive from a topic. These messages are specified in the form of one or more named subscription rules. For each matching rule condition, the subscription produces a copy of the message, which can be differently annotated for each matching rule. For more information, see Topic filters and actions.

We allow streams to be comprised of multiple subjects including ones with wildcards. Consumers are allowed to filter messages based on subjects. NATS is payload agnostic so message selection based on contents is not possible. We do have a strategy for implementing semantically aware filtering but this will not be in V1.

Autodelete on idle
Autodelete on idle enables you to specify an idle interval after which a queue is automatically deleted. The minimum duration is 5 minutes. For more information, see the QueueDescription.AutoDeleteOnIdle Property.

We currently do not support this

Duplicate detection
An error could cause the client to have a doubt about the outcome of a send operation. Duplicate detection enables the sender to resend the same message. Another option is for the queue or topic to discard any duplicate copies. For more information, see Duplicate detection.

All messages that are delivered to consumers have information on sequence number both for the stream and this consumer as well as delivery count.

Security protocols

Service Bus supports security protocols such as Shared Access Signatures (SAS), Role Based Access Control (RBAC) and Managed identities for Azure resources.

We have authz and authn for NATS, more information can be found here - https://docs.nats.io/nats-server/configuration/securing_nats

[kozlovic]

Batching
Client-side batching enables a queue or topic client to delay sending a message for a certain period of time. If the client sends additional messages during this time period, it transmits the messages in a single batch. For more information, see Client-side batching.

We currently do not support this, NATS is extremely performant and JetStream in early tests shows excellent performance as well for a persistent system, so no need at the moment

Actually, by nature, NATS clients do somewhat batch messages since publish() calls are really adding message to a buffer that is flushed when reaching a certain size or asynchronously. Therefore, for high rate publish calls, messages are naturally batched. But it is true that application cannot control how many messages go into a "batch" and when to send that batch.

Duplicate detection
An error could cause the client to have a doubt about the outcome of a send operation. Duplicate detection enables the sender to resend the same message. Another option is for the queue or topic to discard any duplicate copies. For more information, see Duplicate detection.

All messages that are delivered to consumers have information on sequence number both for the stream and this consumer as well as delivery count.

I think this is about a sender: "client to have a doubt about the outcome of a send operation", and I know NATS Streaming does not have such feature, and I believe JetStream neither.

[mariomuja]

Thanks to both of your for taking the time to make the difference clear. It helps a lot to have a clear statement, which features exist and which don't and how the roadmap looks like.

[derekcollison]

We appreciate any and all feedback, and if there are features that you feel are critical please let us know and why you feel the feature is critical. We want to make NATS and JetStream something that folks enjoy using.

[bruth]

Hi @mariomuja, I wanted to check in on this issue since some time has passed and NATS (with the JetStream subsystem) has been released and gone through a good amount of maturation over the past three years.

Have you kept up with the progress? Are you still interested? Happy to provide an updated run-down if so.