What we build with it
NATS is how services talk to each other without knowing about each other. A service publishes that something happened; whichever services care subscribe. Nothing in the publisher's code needs to change when a new consumer appears, which is the property that keeps a system from turning into a web of direct HTTP calls between everything.
It also does request/reply, so it can replace service-to-service HTTP where you want the routing and retries handled for you rather than reimplemented in each client.
Where it fits
Between backend services, alongside Go — real-time fan-out, event notification, and decoupling the thing that records an event from the things that react to it.
The reason we reach for NATS specifically is operational weight. It is a single small binary with a simple configuration, which is a very different commitment from running and tuning a full broker cluster for a system that does not yet need one.
When we recommend it
When you have more than a couple of services and they are starting to call each other directly, or when you need events delivered to a set of consumers that will grow.
Not for a single-service product — an in-process queue or Redis is less to run and does the job. And if you need long-term durable event storage with replay across large retention windows, a log-oriented system is the better fit; NATS with JetStream covers a lot of that ground, but pick it deliberately rather than by default.