NATS VS nanomsg

For the past decade, Kafka has been the default choice for distributed messaging. Its high throughput, durable storage, and rich ecosystem make it a great fit for centralized data pipelines. But edge computing breaks every assumption Kafka was built on. Edge devices have limited RAM (often 128MB-2GB), intermittent connectivity, no dedicated DevOps support, and strict power constraints. Kafka’s JVM-based architecture, 2GB+ memory footprint, and dependency on ZooKeeper or KRaft coordinators make it a nightmare to operate at the edge. I’ve spent the last 4 years contributing to the NATS project (https://github.com/nats-io/nats-server) and migrating 3 enterprise clients from Kafka to NATS for edge workloads. In every case, we saw 80%+ cost reductions and order-of-magnitude latency improvements. The conventional wisdom that “Kafka is the best messaging broker for every use case” is simply wrong for edge.

Subject-level boundary constraints. In an event-driven architecture built on NATS, the paths that cross from edge to core aren't open by default, they're explicitly defined. You configure which subjects are local to the edge leaf node, which are permitted to cross the boundary, and which are strictly core-only. A compromised edge node can't suddenly start publishing to a core command channel; the topology simply doesn't permit it. Synadia's decentralized security model extends this further as credentials are cryptographically scoped, not centrally issued, which means there's no single credential store to compromise.

NATS and the Synadia Platform are purpose-built for exactly this architecture: leaf node topologies that treat edge clusters as first-class entities, JetStream for local durability and controlled forwarding, decentralized security for tightly scoped credentials, and end-to-end observability across the full mesh.

I think jetstream storage is about to get s3 api support https://github.com/nats-io/nats-server/discussions/5486 . also you can use bento connector to connect it to any pipeline you could possibly want. It is easy to manage and works great

It's a workshop with a Discord community of like-minded engineers. In this workshop, we are going to do the irrational thing. We are going to build a NATS-compatible Distributed Pub/Sub server from scratch.

NATS and Synadia's other tech is easy to understand. You're not the target demographic for the Synadia site. They're targeting enterprise.

You can find the NATS site here [1]. NATS is so flexible it's admittedly easy to get lost in what exactly it is or what it's good for. The easy explanation is it's a message broker that can let programs send and receive messages to each other. Unlike a message queue, it has no persistence. Clients can that express "interest" in a topic receive messages to that topic, but messages disappear if nobody listens to them. It's kind of like UDP without addresses. It's clustered and supports complicated topologies where clusters route messages to each other, and has a powerful ACL system for exposing clusters to unprivileged actors that shouldn't be given full access (which means you can easily make it multi-tenant). The closest comparable technology might be MQTT, and indeed NATS offers an MQTT mode.

NATS also has a bunch of higher-level stuff built on top of it: A Kafka-like "stream" feature called Jetstream, RPC, a key/value store, an object (blob) store, and so on. The NATS message bus is the core primitive that these features use.

[1] https://nats.io/

The wasmCloud lattice is its networking layer. This can seem a bit strange when considering that this a NATS instance.

At the core, NATS is a cloud-native messaging system written in go, which enables applications communicate via Publish/Subscribe pattern. Now you will get the idea on where we are going :). NATS also supports other messaging patterns like Request/Reply and Streaming support with it's inbuilt JetStream functionality. We're going to use NATS's Pub/Sub functionality to transfer messages between actors in our Actor Model.

> Jetstream clusters don't scale to many servers (they recommend max 3, I think)

I suspect it just runs a single Raft group – like etcd!

Jetstream is even more limited than most Kafkas on number of streams https://github.com/nats-io/nats-server/discussions/5128#disc...

I've had a look at some open source libraries that already support networking on different platforms like nanomsg, but I can't really tell how the library includes it's headers. My current idea is to use the processors to include the right headers for each system, and then each function would do the same. In a makefile I would do the same for linking correctly. Is this a good method, or is there an easier way? Or does it not matter overall as long as the library works?