NATS VS watermill

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'm using Watermill for the event bus with Redis Streams as the backend. Redis Streams has this concept of consumer groups; consumers in the same group split messages between them, while different groups each receive all messages.

I’ve successfully worked on projects using an asynchronous event-driven way of connecting services. I really like the decoupling of business logic and the events triggering it. I highly recommend https://github.com/ThreeDotsLabs/watermill to be more flexible when it comes to choosing the actual technology driving the async patter. It might be NATS today but requirements might change and you need to change. Watermill prepares you for this.

Highly recommend https://watermill.io lib for building async apps (using among others pub/sub patterns). It greatly decouples your code from the underlying technology and gives you the freedom to choose depending on the environment (e.g dev, prod). For dev or small scale purposes, it supports pub/sub purely based on go channels.

Look at this library: https://github.com/ThreeDotsLabs/watermill

Watermill is a good pubsub abstraction. You can start with native go channels and grow into a cloud pubsub or Kafka/Pulsar if you need to.

These conditions have led me to discover two packages watermill.io and go-kit. Both of these seem to do what I want and I am thinking of implementing the project using watermill and go Chanels and deploying to a server or some sort.

github.com/ThreeDotsLabs/watermill package provides a framework for building event-driven applications. It allows easy communication between independent components by decoupling the sender and the receiver.