Hacker News Reader

Comment by vorpalhex | Hacker News Reader

NATS isn't actually using a log structure though, it's a streaming message broker with a different set of consistency/delivery promises.

View on HN

Correct; but I've seen many uses of Kafka that NATS could totally be used for. For example, load balancing across subscribers (use a NATS queue instead of a Kafka consumer group).

NATS doesn't ever store messages persistently; but this might be fine for your application, and then you don't have to worry about setting 5 different config options to make sure Kafka actually frees up disk space like you expect it to ;)

NATS also enables some unique patterns like request/reply via a "reply to" message header.

Anyway, it's been a joy to use!

Sounds more like rabbitmq replacement than kafka

> NATS doesn't ever store messages persistently

Not true. Both Nats streaming and the upcoming jetstream (core nats) do.

It depends what you mean by 'persistently'. Normally NATS streaming will delete the messages after they have been delivered to all subscribers successsfully and some expiration time has passed.

The expiration time can be unlimited, just like kafka

I'm aware, I was referring to the core binary, `nats-server`. NATS streaming server seems to be still receiving attention, but the client library (for Java) hasn't been committed to since 2019, so I'm not sure I'd build a new project with it. JetStream is out (as of this week, I believe) and is an optional module to `nats-server`, as you said.

To the folks at Synadia -- I love NATS, but the naming and organization of these projects could use some work. What's with the `stan.*` repository names? Where did "jetstream" come from? Why is it baked into `nats-server` but `nats-streaming-server` isn't? Is `nats-streaming-server` on the back burner?

Stan is nats streaming. The clients don't have to be updated since they're forward compatible since jetstream. NATS streaming will be deprecated after jetstream is GA is my understanding. Is there a bug in the library you found?

you also don't have to worry about those kinds of configuration gotchas if you use confluent cloud!

Only you have to be a billionaire to use the confluent cloud.

So I guess pay as you go is too expensive for your org? Be curious to understand why you feel it's too expensive when it completely extrapolates any kafka management.

relative to more mature Kafka cloud services, it's crazy expensive.

Reply on news.ycombinator.com