About a year ago, I was working on a project at my previous job. The goal was to set up a reliable message queue. Most people might go straight to RabbitMQ, and I almost did too. But I decided to look for something different. That's when I came across NATS JetStream. After working with it for the past year, I can say it's truly impressive. It's fast, it can handle a lot of data, and it fits well with cloud systems. Today, I'll walk you through how to use NATS JetStream with a Golang app. By the time you finish reading this article, you'll be able to implement a robust and fast message queue. Message queues For those who are not familiar, what are message queues? In the real world, message queues help systems talk to each other without getting overwhelmed. For example, when you order something online, your order might go into a message queue before it's processed. This way, even if many people order at the same time, the system can handle it smoothly. Message queues are key for making sure data gets where it needs to go, especially when things get busy. Project requirements For my project, I had a clear list of needs when it came to selecting a message queue: : It was crucial that our messages stayed safe. We couldn't afford to lose them due to network glitches or if a server needed to restart. In simple terms, once a message is in the queue, it should stay there until it's processed. Durable Queues : Sometimes, there can be small issues or temporary errors when a system tries to read a message. I needed a way to send these messages back into the queue so they could be tried again later. This ensures that no message gets left behind because of short-term problems. Retrying Messages : As our system might get more users and data, I wanted our message queue to grow easily with us. Horizontal Scaling With these requirements in mind, I began my search for the perfect message queue solution. Possible solutions When searching for the right message queue, I explored several options. Here's a brief overview: : I didn't dive too deep into these. They're older and seem to lack current support. Gearman, Beanstalkd, and similar : It's favored by many small businesses. However, I found it a bit slow. Setting the HA (High-available) cluster requires real expertise. Plus, it lacks the ability to “requeue” a message with delay. RabbitMQ : It's excellent for PubSub and storing KV data. But as a queue system? Not the best. If Redis is set to store all messages, it slows down drastically. Redis : It's a strong choice for event streaming. But it’s not the best choice for message queues. For instance, how can I requeue a message? Apache Kafka : It looked promising and fits the needs of large organizations. It met most of my criteria. Yet, horizontal scaling isn't straightforward. It demands a large infrastructure and a skilled team, which felt excessive for my project's scale. Apache Pulsar Finally, I stumbled upon NATS JetStream. It seemed to align perfectly with my requirements. How NATS JetStream fits to requirements To understand how NATS JetStream works, I made some simple code and did tests. Here's what I learned: : : Setting Things Up I made two simple Golang CLI tools One for sending messages (NATS publisher) ...
publishedTotal := 0
for i := 0; i < 30000; i++ {
	subject := "test_subject_name"
	_, err = jetStream.PublishAsync(subject, []byte(strconv.Itoa(i)))
	if err != nil {
		return fmt.Errorf("publish: %w", err)
	}

	publishedTotal++
}
fmt.Printf("published %d messages\n", publishedTotal)
... One for fetching messages (NATS consumer) ...
totalReceived := int32(0)
for {
	func() {
		ctx, cancel := context.WithTimeout(context.Background(), 3*time.Second)
		defer cancel()

		msgs, fetchErr := jetStreamSubscriber.Fetch(1, nats.Context(ctx))
		if fetchErr != nil {
			if errors.Is(fetchErr, context.DeadlineExceeded) {
				return
			}

			log.Printf("sub fetch err: %s\n", fetchErr)
			return
		}

		for _, msg := range msgs {
			ackErr := msg.Ack()
			if ackErr != nil {
				log.Printf("sub ack err: %s\n", ackErr)
			}
			totalReceived++
			log.Printf("total received: %d\n", totalReceived)
		}
	}()
}
... Durable queues With these tools ready, I checked a few things: : Sending Many Messages : What if I send thousands of messages all at once? Question : The consumers took all the messages in. Nothing was lost. Answer : Sending Without Consumer : What if I send messages but there's no one to consume them? Question : When a consumer is ready, it receives all the messages. Answer : NATS Server Issues : How do consumers act if the NATS server stops? Do they try to connect again when NATS is back? Question : Yes, consumers connect back to NATS by themselves when it's working again. Answer : Unread Messages and NATS Problems : What about messages sent to NATS but not consumed, and then NATS server turns off? Question : If NATS starts working again, all the waiting messages are consumed. This is because NATS keeps messages safe on the computer's storage. Answer NATS showed excellence aligning our first requirement. Let’s check out how it can send messages back to a queue. Requeue In NATS JetStream, requeuing a message that has encountered a problem is straightforward. You can achieve this by calling the function available in the message API. Invoking ensures that the message is sent back to the queue, effectively providing a second chance for it to be processed at a later time. Nak() Nak() Another feature that adds to the utility of NATS JetStream is the ability to requeue messages with a custom delay. This functionality comes in handy when dealing with tasks that are deferred and need to be carried out after a certain period has elapsed. For example, if you have a notification system that must send alerts at specific intervals, you can use this feature to schedule these messages accurately. Two requirements are nailed. There is one more important point about scalability. Horizontal Scaling When it comes to horizontal scaling, NATS JetStream makes the process relatively simple. Setting up a cluster involves running multiple NATS servers with JetStream enabled. All that's required is to specify the same and define the routing paths between each node in the configuration. cluster_name I added an example of docker-compose.yml file to run a local NATS cluster: version: "3.5"
services:
  nats1:
    container_name: nats1
    image: nats
    entrypoint: /nats-server
    command: --server_name N1 --cluster_name JSC --js --sd /data --cluster nats://0.0.0.0:4245 --routes nats://nats2:4245,nats://nats3:4245 -p 4222
    networks:
      - nats
    ports:
      - 4222:4222

  nats2:
    container_name: nats2
    image: nats
    entrypoint: /nats-server
    command: --server_name N2 --cluster_name JSC --js --sd /data --cluster nats://0.0.0.0:4245 --routes nats://nats1:4245,nats://nats3:4245 -p 4222
    networks:
      - nats
    ports:
      - 4223:4222

  nats3:
    container_name: nats3
    image: nats
    entrypoint: /nats-server
    command: --server_name N3 --cluster_name JSC --js --sd /data --cluster nats://0.0.0.0:4245 --routes nats://nats1:4245,nats://nats2:4245 -p 4222
    networks:
      - nats
    ports:
      - 4224:4222

networks:
  nats:
    name: nats What adds to the utility is that you can connect to any node within the cluster, whether from a publisher or a consumer application, and it just works seamlessly. This implies that the system is designed to handle varying load distributions, routing the messages effectively irrespective of which node you are connected to. It was clear to me that NATS JetStream aligned with all my requirements perfectly. Pros and nuances I spent considerable time with NATS JetStream and can outline its strengths and limitations based on my experience: Pros : NATS JetStream is more than just a message queue system. It offers a variety of features that I'll elaborate in the next articles. Broad Functionality : Being written in Go, the source code is accessible and provides insight into undocumented functionalities. This is particularly useful for Go developers who want to delve deeper into the system. Go-Based : The performance metrics for NATS JetStream are impressive, making it a reliable choice for high-throughput scenarios. Strong Benchmarks Nuances : One thing to be aware of is that NATS ensures 'at-least-once' message delivery. As a result, your consumer logic must be idempotent to handle such cases. 'At-Least-Once' Delivery : While the documentation is generally good, it doesn't cover all configuration options. Sometimes, you'll need to go through the SDK code to understand certain functionalities fully. Incomplete Documentation : This could be seen as both a pro and a nuance. The SDK handles reconnections automatically, which means you don't have to code this logic yourself. Built-In Reconnection Logic Performance The performance benchmark was conducted by , where NATS JetStream was compared with other popular message queues like Apache Pulsar and RabbitMQ. It's important to approach these results with a degree of skepticism, as the company is known for its affinity towards Apache Pulsar. They themselves noted that they faced difficulties in configuring NATS JetStream for the benchmark, which could potentially skew the results in favor of their preferred system. Steamnative NATS JetStream – During our tests, we attempted to follow the recommended practices for deliverGroups and deliverSubjects in NATS, but encountered difficulties. Our NATS subscriptions failed to act in a shared mode and instead exhibited a fan-out behavior, resulting in a significant read amplification of 16 times. This likely significantly impacted the overall publisher performance. Conclusion After working with NATS JetStream for an extended period, several aspects of the system became apparent: Easy configuration. High performance. Broad functionality. Beyond its capabilities as a message queue, NATS JetStream also functions as a message broker for event-streaming, PubSub, and synchronous Request-Reply message bus. While this article provides an initial overview, I plan to discuss the diverse features of NATS JetStream in more detail in future articles. This will include a closer look at its specific functionalities and how they can be applied in different scenarios. References NATS JetStream Publisher/Subscriber demo code Comparison of NATS, NATS Streaming and NATS JetStream Implementing NATS JetStream as Queues in Golang Steamnative performance benchmark Steamnative performance benchmark (detailed)

Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.

The code in this story is for educational purposes. The readers are solely responsible for whatever they build with it.

2022 - HackerNoon Contributor of the Year - Algorithms

2022 - HackerNoon Contributor of the Year - Chatbots

2022 - HackerNoon Contributor of the Year - Facebook

2022 - HackerNoon Contributor of the Year - Golang

2022 - HackerNoon Contributor of the Year - How To

Nominated for 2022 - HackerNoon Contributor of the Year - Algorithms

Nominated for 2022 - HackerNoon Contributor of the Year - Golang

Nominated for 2022 - HackerNoon Contributor of the Year - How To

Nominated for 2022 - HackerNoon Contributor of the Year - Chatbots

Nominated for 2022 - HackerNoon Contributor of the Year - Facebook

Too Long; Didn't Read

In your car, at home, or at work — Bosch technology shapes many areas of life.

NATS JetStream — a New Way to Create Resilient Message Queue

Too Long; Didn't Read

Vladislav Gukasov

STORY’S CREDIBILITY

Guide

Code License

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

NATS JetStream — a New Way to Create Resilient Message Queue

Too Long; Didn't Read

Vladislav Gukasov

STORY’S CREDIBILITY

Guide

Code License

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES