A hammer lying on a table surrounded by nails that were driven into the table with varying degrees of success

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

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.