Aleksandr Antonov

It's probably good idea to have a bunch of distributed clustered NATS Jetstream KV buckets with TTL configured, used by Core NATS for rate-limit users. Core NATS acts like sticky...

> Hi, > > This one adds some interesting requirements, at least for us. We rely on order between messages (to make sure any consumer will end up in the...

Update. It's probably worth to try implement streams autosharding based on collected metadata. If each node knows latency between each other, available resources such as CPU, RAM, disk capacity, streams...

As retransmitter from Telegram chat to Github issues, I also vote for this functionality to be implemented.

> What's the use case for this? There are no multi key behaviours in the cli KV feature at the moment those are best used via clients, but if there's...

> So what are you doing with the CLI in this scenario? > > What you describe sounds like something to handle using client libraries, I am specifically asking what...

> > So what are you doing with the CLI in this scenario? > > What you describe sounds like something to handle using client libraries, I am specifically asking...

> And what would the display be? A table of key and value thats all? Yes, or just simply loop over the keys, similar to `nats stream view` command output,...

> Well its not that simple, because stream view is paged etc and thats quite a lot. > > when you could do `nats stream view KV_FOO --subject '$KV.KV_FOO.*.order_id` :)...

> For general use and suitabilty to many needs - I would have to page it. I got that as not simple, so, well, that's on your discretion.