Letter 1: NATS, a single binary message bus

Letters to a Human

Letter 1 · NATS, a single binary message busWritten by hand, in spirit

Dear friend,

I came across NATS, stumbled upon it, when I was collecting various patterns for my chief-of-staff coordinator agent to be able to talk to the other teammates. I figured there would be a messaging pattern; this problem would have been solved previously, pre-AI, so I went looking for this.

The thing that stood out was this guy coming up with NATS. This guy had a lot of TIBCO experience, messaging, a Bay Area guy, and he got frustrated with RabbitMQ during a weekend and stood up NATS. When he later explained this as “this is like electricity in the house, and you don't need a platform. For this tower, it should be like a dial tone,” it made sense, on why he shipped a single binary for this.

It is like a live radio: publish, and if there are listeners they will listen; otherwise it gets lost.

A hand drawn sketch of NATS as a live radio A small radio tower, the single binary, sends live waves out to hand drawn radios tuned in live. One radio arrives late and misses the broadcast. Below, a dashed sketch box labeled JetStream, optional, catches and holds the broadcast so the late listener can replay it. live, right now the broadcaster, one single binary tuned in, they hear it JetStream, optional catches it, holds it arrives late, missed it live but can replay it
One broadcast, live for whoever is listening, and kept only if JetStream is on.

He later rewrote it in Go, and Go's goroutines, tiny threads the runtime juggles by the thousands, meant one server could hold a huge crowd of listeners without paying a full thread for each one. So fan-out stayed cheap.

They later on added JetStream, which gave persistence to NATS and allowed for streaming, but that is also packed in within a single binary.

The nice and intuitive thing is subject-based addressing. He wanted a way to not depend on IP networks, so he started from “how do I express interest in data?” versus what was going on around that time, which is “how do I express interest in this machine?” previously. The other products in the market were not doing subject-based addressing, because they had other problems to solve for, like scale. Kafka gave you a log, but you have to read from the whole log, because they prioritized throughput.

Tinder uses it to tell you, in real time, that you have a new match or message. First, the app holds a live WebSocket connection to Tinder's servers, so the server can reach the phone instead of the phone asking every two seconds. Then, when a match or message is created, the backend sends a tiny nudge, and NATS routes that nudge to the topic named for that user. The service listening to that topic pushes it to every device that user has open, and the app fetches the actual match or message.

It is easy to miss NATS, and I am glad I came across it, because often times you get drowned out by Kafka, RabbitMQ, SQS, etc. for pub/sub and streaming, nice to know there are simpler packaged options out there.

Yours,

Phani