Hacker News Reader

Comment by nine_k | Hacker News Reader

So, basically it's an in-process, single-threaded KV store, made out of a standard JS Object with a bunch of operations over keys or values, vaguely along the lines of Redis.

These operations make it stand out a bit from just typing `const kV = {}`, especially set operations, and the presence of TTL for keys.

Could be useful. For me though the usefulness of Redis comes mostly from its being a common store across many processes / nodes, so it can serve ads a cache, a queue, etc. Maybe it's also useful for a single JS process in a similar capacity.

View on HN

What I've wanted before is an easy in-memory NodeJS (typescript) cache that multiple processes can share. Like, we deploy on AWS EC2s with multiple vCPUs; I don't want a separate in-memory cache for each of them, but I also don't want the latency of Redis.

You can run Redis on the same machine with a Unix socket to share it between processes without the network latency

Could you use Kubernetes to solve this? Have a single pod running the Redis instance and then multiple running Node.js talking to the Redis instance via something like DAPR (https://dapr.io/)

Yes, but the question is should you. If you already have Kubernetes knowledge and infrastructure, why not? Otherwise, maybe not.

Yeah I should be clear, I meant this question purely as a curiosity, not a recommendation.

I'm a PM, trying to properly understand K8's, definitely not providing recommendations hahaha.

Wouldn't Kubernetes and/or Dapr just add even more latency before the packets reach Redis?

It seems like the parent comment's author is implying that Redis is already too slow even when running it on bare metal and connecting directly to it.

Adding additional things like service discovery and proxies in the network path will not speed it up. To speed it up you would need to bring Redis closer, so perhaps you meant using k8 tools like "pod topology spread contraints" to do so (juxtaposing with the default k8 behavior that may spread workloads out in an undesirable manner)?

Simply going from "we are not using k8s" to "we are using k8s" won't speed up latency to Redis.

I was under the assumption OP's redis instance was running on a separate machine and they wanted to be and to achieve a setup that "felt like" it was distributed (container isolation, etc) but without the network hops adding in latency.

My question was more around whether you could use K8's to effectively simulate that, but on a single beefy machine to remove the network hops.

It was also a curiosity "is this possible" type of question, not an "I'm saying this is a good idea" type of question.

The irony of having someone comment on the complexity of running bare redis on the same server, only for someone else suggesting a whole Kubernetes setup for essentially the same thing.

If you're already heavily invested in Kubernetes this is certainly a solution, though I feel this adds too much abstraction for the amount of problem it's solving.

If you already have a k8s setup, and the Redis is but a small addition to it, this may make sense.

Using k8s to solve just that would of course be overkill.

Yeah I should be clear, I meant this question purely as a curiosity, not a recommendation.

What you mean by Redis latency? It should be pretty much minimal, I don't know any IPC setups that would be faster

Reply on news.ycombinator.com