Throughout my career, I’ve used many different flavours of message brokers. Back in the day, I started out using Tibco EMS, and since then, I’ve built systems with most of the MQs and, more recently, Kafka.

I’m comfortable with the message-broker paradigm and recognise its value within a system’s architecture. So I am always looking for what’s new and innovative in this space, and the stack that has caught my eye most recently is NATS.

What’s the big deal?

NATS can seemingly do it all…

• Pub-Sub
• Request-Reply
• Load-balancing with Queue Groups
• Subject mapping and partitioning
• Persistent streams
• Key/Value store
• Object store
• Multi-tenancy from the ground up
• Clusters of clusters

At face value, NATS is a one-stop shop for all your architectural needs. And whilst I have just started kicking the tyres, I must admit it is exceeding my expectations so far.

Over the coming weeks and months, I will be fleshing out my ideas for leveraging NATS within the two areas I’m working in currently: Nix and Ethereum.

I have already started with ENATS, a data fabric of sorts for Ethereum execution clients. There I’m exploring ideas for leveraging subjects to naturally load-balance requests across instances, and I want to see what I can do with the Key/Value store for caching and so on.

But I also plan to spend the next while looking at Nix-focused applications. Currently, I’m toying with a Nix binary cache backed by NATS, and it’s helping me better understand NATS’s isolation and security model.

There will, of course, be a series of follow-up blog posts detailing just how I get on with these various endeavours. But in the meantime, I felt I should get the word out.

NATS is pretty cool, and it’s worth having a look.