You've built a great SaaS product. Your backend is a clean set of microservices. You're using Kafka for async communication between them. Life is good.

Then a large enterprise customer signs up.

They want your platform to connect to their internal systems — a CRM, an ERP, a data warehouse sitting inside their private corporate network. You say sure, we'll just call your API. They say... "our servers are not publicly accessible."

You ask them to open a firewall port. Their security team says no.

You suggest a VPN. Their IT team says that'll take 3 months to approve.

And just like that, your SaaS product has hit an invisible wall that no amount of clever code can break through.

This is a problem that thousands of SaaS companies run into — and very few have a clean answer for. This article is about how NATS gave us that clean answer.

First, Let's Talk About How We Got Here

The Microservices Promise

When we moved from a monolith to microservices, we immediately needed a way for services to talk to each other without being tightly coupled. Service A shouldn't have to know that Service B even exists, let alone its URL.

That's why message brokers became standard. Instead of calling each other directly, services publish events to a central broker. Other services subscribe and react. Everyone is decoupled. It's beautiful — in theory.

Why We Chose Kafka

Kafka is the most popular choice, and for good reason. It's battle-tested, it handles massive volumes of data, and it has a rich ecosystem of tools. For internal service communication — Order Service publishing events that Payment Service consumes — it works well.

But here's what we slowly discovered: Kafka is built for a very specific job — high-throughput data streaming inside a controlled network. It assumes everything is on the same network, or at least that you control both ends.

When reality doesn't match that assumption, things get painful.

The Moment Kafka Wasn't Enough

Scenario: Syncing with Customer's Private Server

Imagine your SaaS platform needs to push processed data back to a customer's on-premise server in real time. Maybe it's a healthcare company syncing records to their local database. Maybe it's a manufacturing plant syncing events from your platform to their floor systems.

Here's what your first instinct looks like:

Simple. Except it doesn't work. Because the customer's server is behind a corporate firewall, and no inbound port is open to the outside world. Your HTTP request hits a wall.

Your second instinct:

Still doesn't work. Kafka requires the broker to be reachable. If you run the broker in your cloud, the customer's on-premise consumer needs to reach it on specific ports — which the firewall blocks. If you try to run a Kafka consumer inside their network, it needs to connect out to your broker, which is possible, but Kafka wasn't designed for this topology. It becomes a networking project.

The Real Root Cause

The fundamental issue is who opens the connection.

Traditional networking assumes the client (the one who wants data) calls the server (the one who has data). Firewalls are designed around this — they block inbound connections from the outside, but allow outbound connections from the inside.

A corporate firewall lets employees browse the internet (outbound). It blocks hackers from reaching internal servers (inbound). That's the whole point.

So if your SaaS is trying to push data into the customer's network, you're going inbound — and the firewall stops you every time.

What we needed was a system where the customer's side initiates the connection outbound — and then communication flows both ways through that single outbound tunnel.

That's exactly what NATS does.

Enter NATS

What Is NATS?

NATS is a messaging system — like Kafka, but designed from the ground up for a different world. While Kafka is a freight train optimized for carrying massive loads along a fixed track, NATS is more like a smart postal network that routes messages anywhere, even across network boundaries that shouldn't logically be crossable.

The NATS server is a single tiny binary — about 20 MB. No Java, no JVM, no ZooKeeper, no Kafka Connect. It starts in under a second. The entire thing uses less memory than Kafka's idle footprint.

For pure internal streaming at Petabyte scale, Kafka wins. For everything else — especially when you need to cross network boundaries — NATS is a far better fit.

How NATS Solves the Firewall Problem

The Concept: Outbound-Only Connection

NATS has a feature called Leaf Nodes. Here's the idea in plain English:

You run a small NATS server inside the customer's private network. This small server reaches out to your cloud NATS hub — just like a browser reaching out to a website. It's an outbound connection, so the firewall allows it.

Once that connection is established, messages flow both ways through it. Your cloud services can send data to the customer's systems. The customer's systems can send data back to you. All through that single outbound tunnel that the customer's server opened.

The customer never opens a single inbound firewall port. Their security team is happy. You get real-time, two-way communication with their private systems.

What Happens When the Connection Drops?

This is where it gets really elegant. If the customer's internet goes down or the WAN link becomes unstable, the small NATS server on their side doesn't crash — it just keeps serving local apps. When connectivity is restored, it reconnects to your cloud hub and picks up where it left off.

This is called local autonomy. The customer's systems keep working even when the cloud is unreachable.

Understanding NATS Features (The Easy Version)

Now that you understand why NATS exists, let's look at what it actually does. NATS has a few core features that together cover almost everything a distributed system needs.

1. Publish / Subscribe — The Foundation

This is the basic building block. A service publishes a message to a subject (think of it like a topic or channel name). Any service that has subscribed to that subject receives the message.

The publisher has no idea who is listening. It just puts the message out there. This is what makes services decoupled.

Subjects in NATS are hierarchical with dot notation, and you can use wildcards:

• orders.created — exact match
• orders.* — any single word (orders.created, orders.cancelled, etc.)
• orders.> — anything starting with "orders."

This lets a monitoring service subscribe to > and see every message on the entire system.

2. Request / Reply — Async RPC

Sometimes a service needs an answer, not just a one-way notification. NATS has this built in. One service asks a question, another answers.

This happens over the same NATS connection. No separate HTTP server needed. No REST API to maintain. Services speak to each other directly through the message bus.

3. Queue Groups — Load Balancing for Free

If you have 5 instances of your Payment Service all subscribed to the same subject, normally all 5 would receive every message. That's usually not what you want.

With a queue group, NATS automatically load-balances — only one instance gets each message. Scale up by adding more instances. Scale down by removing them. No configuration changes, no rebalancing time. NATS handles it instantly.

4. JetStream — When You Need Persistence

The features above are real-time only. If a service is down when a message is published, it misses that message. For events that must never be lost — payments, orders, audit logs — you need JetStream.

JetStream is NATS' built-in persistence layer. Think of it as giving NATS a memory.

You define a Stream that captures messages on certain subjects and stores them on disk. Then you define Consumers — services that read from that stream at their own pace.

The key benefits:

• At-least-once delivery — if a service crashes mid-processing, the message is re-delivered
• Replay — a new service can replay all historical events from day one
• Consumer lag tracking — you can see exactly how far behind each service is in real time

Think of a Stream as a DVR recording. Even if you weren't home when the show aired, you can watch it later. The Consumer is your remote control — you can pause, rewind, or skip ahead.

5. Key-Value Store — Live Configuration

NATS has a built-in distributed key-value store, backed by JetStream. This sounds simple but it's incredibly powerful in practice.

You can store configuration values in NATS KV, and all your services watch for changes in real time. When you update a feature flag, every running instance of every service sees the new value within milliseconds — no restart required.

You also get full revision history. Want to know who changed what and when? It's all there.

Kafka doesn't have this. You'd need Redis or etcd or Consul separately. With NATS, it's built in.

6. Leaf Nodes — The Firewall Solver (revisited)

As we explained earlier, Leaf Nodes let a small NATS server in a private network establish an outbound connection to your cloud hub. Once connected, the entire NATS feature set — pub/sub, request/reply, JetStream, KV store — works transparently across that connection.

Your cloud services don't even know (or care) that the customer's systems are behind a firewall. They just publish and subscribe to subjects, and NATS routes the messages intelligently.

Why Not Just Use Kafka for All of This?

This is a fair question. Let's be direct about it.

Kafka's strengths:

• Handling millions of events per second (think: clickstream data, logs, telemetry)
• Long-term event storage (days, months, years) with log compaction
• Ecosystem integrations via Kafka Connect (Elasticsearch, S3, databases)

Where Kafka struggles in a SaaS context:

1. It assumes a shared network. Kafka brokers need to be reachable by all consumers and producers. This falls apart the moment a customer's systems are behind a firewall. There's no built-in solution — you end up layering VPNs, SSH tunnels, or custom proxies on top.

2. It's expensive to run per-customer. If every enterprise customer needs their own Kafka cluster (because you can't share topics across security boundaries), you're looking at significant infrastructure costs and operational complexity for each customer onboarding.

3. It's heavyweight for async communication. If you're only using Kafka for passing messages between microservices — not for high-throughput analytics — you're carrying a lot of operational weight for a relatively simple job. A NATS cluster uses a fraction of the memory and CPU.

4. Request/Reply isn't native. Synchronous RPC patterns in Kafka require custom correlation ID implementations. NATS has this built in.

5. No built-in KV or Object store. Features like distributed config and binary artifact storage require separate systems (Redis, S3, etcd) alongside Kafka.

The Architecture We Ended Up With

Here's the high-level picture of how the pieces fit together in a SaaS context:

Each customer runs a small NATS leaf node. It dials out to your hub. From there, everything — data sync, commands, configuration, acknowledgments — flows through that one outbound connection, fully encrypted.

What We Gained

Switching from a Kafka-only architecture to NATS brought us real, measurable benefits:

🔓 We could onboard customers behind firewalls — something that was simply impossible before. No VPN negotiation, no "open this port" emails to IT departments.

📉 Infrastructure costs dropped — NATS uses a fraction of the compute that Kafka needs. For customers who need a local node, the NATS binary runs fine on a $5/month VM or even a Raspberry Pi.

⚡ Latency improved — NATS is designed for low-latency messaging, not high-throughput batching. For real-time sync use cases, messages that took hundreds of milliseconds over Kafka were now single-digit milliseconds.

🧩 We eliminated three separate systems — Kafka (messaging) + Redis (KV/config) + a custom RPC layer were replaced by a single NATS cluster with JetStream.

🛡️ Security became simpler — Every connection in NATS is TLS by default. The customer's leaf node authenticates with cryptographic credentials. No passwords in config files, no shared secrets.

Should You Make the Switch?

Not necessarily — and that's an honest answer.

If your primary use case is ingesting millions of rows of clickstream data, running Kafka Connect pipelines into your data warehouse, or powering an analytics platform, Kafka is the right tool. It was built for that.

But if your use case looks like this:

• Microservices that need reliable async communication
• Real-time sync with customer systems behind firewalls
• Low-latency event delivery rather than high-throughput batching
• Dynamic configuration pushed to services without restarts
• Keeping infrastructure simple and cheap to operate

...then NATS is worth a serious look.

The firewall problem alone — connecting to customer private networks without asking them to open ports — is enough of a reason for many SaaS companies.

A Final Analogy

If Kafka is a freight railway — massive capacity, fixed infrastructure, runs on its own dedicated tracks, needs a lot of setup — then NATS is a courier network — fast, lightweight, finds a way to deliver even when the front door is locked, and doesn't need you to build a railway station to use it.

Both are valuable. Know which job you're hiring for.

Where to Go From Here

If this sparked your interest, here are the best places to learn more:

• 📖 NATS Documentation — clear, well-organized, with real examples
• 🧪 NATS by Example — runnable patterns in every language
• 🎥 NATS on YouTube — architecture deep dives and demos

If this article helped you, share it with a teammate who's battling the same firewall problem. And if you've solved it differently, I'd genuinely love to hear about it in the comments.