NATS turns out to be exactly what I’ve been searching for in a service bus, and not just for this project.

It’s more than just an RPC mechanism, more than just a pub/sub mechanism. It eliminates a lot of the headaches I was having with implementing my own service bus.

Things like service registries are no longer important. Client applications and other micro services don’t need to know where to send a request, it’s just sent.

Everything that needs to be connected is connected, without having to know where they’re located. With Go this is awesome, because it’s just an extension of a channel, which makes it very easy to scale.

You can configure each channel so that a request can be distributed to one or all of the interested services; think of something like map/reduce where you send a query to a “subject”, and a bunch of services receive the query and reply with all of the data matching the query. This could be a basic implementation of a distributed search engine.

Another example would be to configure so that only one service receives the request, allowing you to have a round-robin or other algorithms for distributing request handlers with built-in redundancy.

So, after doing quite a bit of research over the past month, I’ve decided that NATS will be my message bus of choice.

I’ll not discard my current gRPC implementation nor will I discard my mDNS service registry implementation. They might eventually come in handy.

So, I’m off to play with NATS and try out some different configurations to see how they work and which configurations work best for some of the features I’d like to implement.


– Sgt. Flame