Hacker News Reader

Comment by SEJeff | Hacker News Reader

For workloads that aren't as important durability wise, has anyone considered nats? https://nats.io/

I use NATS in production. Kafka and NATS are almost complete opposites. One is a durable, partitioned queue; the other is a no-persistence message queue.

Neither are message queues. NATS is a pub/sub system and NATS Streaming is a client that connects to NATS and stores all messages on certain channels for replay.

Indeed, NATS is a pub/sub system. I should have said "message broker", but defaulted to "queue". Is a zero-depth queue a queue?

> Is a zero-depth queue a queue?

Yes. Queuing semantics are usually about ordered delivery, acknowledgements, consumer groups, retries, priorities, etc. RabbitMQ does that, NATS only has queue groups at most.

Aren't they fixing that with NATS Streaming Server?

There's nothing to "fix" - NATS is a distributed and fast pub/sub system. NATS Streaming is actually a client, it uses NATS to communicate and basically just subscribes to some topics, saves messages it receives, and will then replay them back to you if asked.

Imagine how you would build a persistent logging app on top of NATS, and that's what NATS Streaming is.

We built a metrics relay using it (nats) and are pushing > 500k metrics per second in bursts just fine. I've been pretty blown away with the perf of it actually. That said, it isn't durable, so normal here be dragons warning apply.

They did. Partially. I use nats-streaming in Production. It still does not have real “clustering” solution, but for my small scale I’m able to manage ~7-10k messages per second. Which is fine for many companies.

We use both:

- kafka for firehose data

- nats for realtime, routed data

Reply on news.ycombinator.com