NATS superclusters don’t actually connect regions together; they are the connected regions, forming a single, unified messaging plane.
Imagine you have two NATS clusters, one in us-east-1 and another in eu-west-2. You want them to act as one. This is where superclustering comes in. Instead of treating them as separate entities, you configure them to peer with each other.
Here’s a quick look at a nats-server configuration for a supercluster. Notice the routes section in both configurations.
us-east-1/nats-server.conf:
listen: 4222
http: 8222
cluster {
listen: 6222
routes = [
"nats://eu-west-2-nats.example.com:6222"
]
}
# ... other settings
eu-west-2/nats-server.conf:
listen: 4222
http: 8222
cluster {
listen: 6222
routes = [
"nats://us-east-1-nats.example.com:6222"
]
}
# ... other settings
When these servers start, they’ll establish a persistent connection on their cluster ports (6222 in this example). This connection isn’t just for metadata; it’s a full NATS connection that will carry actual messages.
The magic is that NATS automatically handles routing. If a publisher in us-east-1 sends a message to a subject like orders.us.*, and a subscriber in eu-west-2 is listening to orders.eu., NATS on the us-east-1 side knows to forward that message over the supercluster link to the eu-west-2 cluster. The eu-west-2 server then delivers it to its local subscriber. It feels like one giant NATS server, even though it’s physically distributed.
This solves the problem of creating a single, global messaging backbone for distributed applications. Developers don’t need to worry about cross-region communication logic; they just publish and subscribe as if they were on a local network. NATS handles the rest.
The core mechanism is the routes configuration within the cluster block. Each server in the supercluster lists the cluster addresses of its peers. NATS servers use a gossip protocol to discover other servers within the same supercluster and maintain a consistent view of the topology. When a message arrives, a server checks its local subscriptions. If no local subscriber exists, it consults its routing table (populated by the gossip protocol and active subscriptions) to determine if any other server in the supercluster has a matching subscriber. If so, it forwards the message.
The most surprising thing is how NATS manages state and partitions. If the connection between us-east-1 and eu-west-2 goes down, each cluster continues to operate independently. Subscriptions and publications within each region work fine. When the connection is restored, NATS automatically re-establishes the routes and synchronizes any messages that might have been buffered or published during the outage, provided the message persistence and replay mechanisms are configured. It’s designed for resilience and high availability across unreliable network links.
The next concept to explore is how NATS handles high availability within a single region using NATS JetStream and its replication features.