Cloud Native Messaging System — NATS (Part -2)
This article is in continuation of the Part -1 article published before.If you haven’t read it I would recommend to read it before moving on this article. Link to the article: Cloud Native Messaging System — NATS (Part -1)
What is NATS
Software applications and services need to exchange data. NATS is an infrastructure that allows such data exchange, segmented in the form of messages. We call this a “message oriented middleware”.
With NATS, application developers can:
- Effortlessly build distributed and scalable client-server applications.
- Store and distribute data in realtime in a general manner. This can flexibly be achieved across various environments, languages, cloud providers and on-premises systems.
NATS Client Applications
Developers use one of the NATS client libraries in their application code to allow them to publish, subscribe, request and reply between instances of the application or between completely separate applications. Those applications are generally referred to as ‘client applications’ or sometimes just as ‘clients’ throughout this manual (since from the point of view of the NATS server, they are clients).
NATS Service Infrastructure
The NATS services are provided by one or more NATS server processes that are configured to interconnect with each other and provide a NATS service infrastructure. The NATS service infrastructure can scale from a single NATS server process running on an end device (the
nats-server process is less than 20 MB in size!) all the way to a public global super-cluster of many clusters spanning all major cloud providers and all regions of the world such as Synadia's NGS.
Connecting NATS Client applications to the NATS servers
To connect a NATS client application with a NATS service, and then subscribe or publish messages to subjects, it only needs to be configured with:
- URL: This is a string (in a URL format) that specifies the IP address and port where the NATS server(s) can be reached, and what kind of connection to establish (plain TCP, TLS, or Websocket).
- Authentication: It details for the application to identify itself with the NATS server(s). NATS supports multiple authentication schemes (username/password, decentralized JWT, token, TLS certificates and Nkey with challenge).
Simple messaging design
NATS makes it easy for applications to communicate by sending and receiving messages. These messages are addressed and identified by subject strings, and do not depend on network location.
Data is encoded and framed as a message and sent by a publisher. The message is received, decoded, and processed by one or more subscribers.
With this simple design, NATS lets programs share common message-handling code, isolate resources and interdependencies, and scale by easily handling an increase in message volume, whether those are service requests or stream data.
NATS Quality of service (QoS)
NATS offers multiple qualities of service, depending on whether the application uses just the Core NATS functionality or also leverages the added functionalities enabled by NATS JetStream (JetStream is built into
nats-server but may not be enabled on all service infrastructures).
- At most once QoS: Core NATS offers an at most once quality of service. If a subscriber is not listening on the subject (no subject match), or is not active when the message is sent, the message is not received. This is the same level of guarantee that TCP/IP provides. Core NATS is a fire-and-forget messaging system. It will only hold messages in memory and will never write messages directly to disk.
- At-least / exactly once QoS: If you need higher qualities of service (at least once and exactly once), or functionalities such as persistent streaming, de-coupled flow control, and Key/Value Store, you can use NATS JetStream, which is built in to the NATS server (but needs to be enabled). Of course, you can also always build additional reliability into your client applications yourself with proven and scalable reference designs such as acks and sequence numbers.
We have provided Walkthroughs for you to try NATS (and JetStream) on your own. In order to follow along with the walkthroughs, you could choose one of these options:
natsCLI tool must be installed, and a local NATS server must be installed (or you can use a remote server you have access to).
- You can use Synadia’s NGS.
- You could even use the demo server from where you installed NATS. This is accessible via
nats://demo.nats.io(this is a NATS connection URL; not a browser URL. You pass it to a NATS client application).
Installing the nats CLI Tool
brew tap nats-io/nats-tools
brew install nats-io/nats-tools/nats
For Arch Linux:
For other versions of Linux and for Windows: The
.rpm files and Windows binaries (even for ARM) are available here Github Releases.
Installing the NATS server locally (if needed)
If you are going to run a server locally you need to first install it and start it. Alternatively if you already know how to use NATS on a remote server, you only need to pass the server URL to
nats using the
-s option or preferably create a context using
nats context add, to specify the server URL(s) and credentials file containing your user JWT.
Installing the NATS server via a Package Manager
On Mac OS:
brew install nats-server
choco install nats-server
On Arch Linux:
For other versions of Linux or other architectures, you can install a release build as shown below.
Downloading a Release Build
You can find the latest release of
You could manually download the zip file matching your systems architecture, and unzip it. You could also use
curl to download a specific version. The example below shows for example, how to download version 2.6.2 of the
nats-server for Linux AMD64:
curl -L https://github.com/nats-io/nats-server/releases/download/v2.6.5/nats-server-v2.6.5-linux-amd64.zip -o nats-server.zipunzip nats-server.zip -d nats-serverArchive: nats-server.zip
and finally, copy it to the
bin folder (this allows you to run the executable from anywhere in the system):
sudo cp nats-server/nats-server-v2.6.2-linux-amd64/nats-server /usr/bin
Start the NATS server (if needed)
To start a simple demonstration server locally, simply run:
nats-server(or nats-server -m 8222 if you want to enable the HTTP monitoring functionality)
When the server starts successfully, you will see the following messages:
 2022/09/25 22:53:53.525530 [INF] Starting nats-server
 2022/09/25 22:53:53.525640 [INF] Version: 2.6.1
 2022/09/25 22:53:53.525643 [INF] Git: [not set]
 2022/09/25 22:53:53.525647 [INF] Name: NDAUZCA4GR3FPBX4IFLBS4VLAETC5Y4PJQCF6APTYXXUZ3KAPBYXLACC
 2022/09/25 22:53:53.525650 [INF] ID: NDAUZCA4GR3FPBX4IFLBS4VLAETC5Y4PJQCF6APTYXXUZ3KAPBYXLACC
 2022/09/25 22:53:53.526392 [INF] Starting http monitor on 0.0.0.0:8222
 2022/09/25 22:53:53.526445 [INF] Listening for client connections on 0.0.0.0:4222
 2022/09/25 22:53:53.526684 [INF] Server is ready
The NATS server listens for client connections on TCP Port 4222.
Fundamentally, NATS is about publishing and listening for messages. Both of these depend heavily on Subjects.
What is a Subject?
At its simplest, a subject is just a string of characters that form a name which the publisher and subscriber can use to find each other. It helps scope messages into streams or topics.
Characters allowed for subject names
For compatibility across clients, we recommend using ASCII characters (this may change in future).
- Recommended characters:
9(names are case sensitive, and cannot contain whitespace).
- Special characters: The period
.(which is used to separate the tokens in the subject) and
>are used as wildcards).
- Reserved subject names: By convention subject names starting with a
$are reserved for system use (e.g. subject names starting with
. character is used to create a subject hierarchy. For example, a world clock application might define the following to logically group related subjects:
NATS provides two wildcards that can take the place of one or more elements in a dot-separated subject. Subscribers can use these wildcards to listen to multiple subjects with a single subscription but Publishers will always use a fully specified subject, without the wildcard.
Matching a Single Token
The first wildcard is
* which will match a single token. For example, if an application wanted to listen for eastern time zones, they could subscribe to
time.*.east, which would match
Matching Multiple Tokens
The second wildcard is
> which will match one or more tokens, and can only appear at the end of the subject. For example,
time.us.> will match
time.us.* would only match
time.us.east since it can't match more than one token.
Monitoring and Wire Traps
Subject to your security configuration, wildcards can be used for monitoring by creating something sometimes called a wire tap. In the simplest case you can create a subscriber for
>. This application will receive all messages -- again, subject to security settings -- sent on your NATS cluster.
* can appear multiple times in the same subject. Both types can be used as well. For example,
*.*.east.> will receive
It is recommended to keep the maximum number of tokens in your subjects to a reasonable value of 16 tokens max.