Hacker News Reader

Comment by googletron | Hacker News Reader

I wrote a little post on how Redis works and its various setups! How does everyone setup Redis? Elasticache is a good answer too :P

View on HN

[Potentially inaccurate content removed by author]

The saltiness isn't a good look here. Especially seeing as he's not the poster.

It's the HN algorithm which is probably due to the fact that other posts from his domain have done relatively well, plus the actual poster here has quite a bit of karma.

It's a new article so it's relatively easy to explain:

HN automatically combines submissions so that subsequent submissions count as upvotes for the first submission.

If a popular source posts a new article, users will "rush" to post it to HN to reap that sweet karma and the winner will "catch" the upvotes of the others.

That could explain it. Thanks!

Is this behavior documented anywhere on news.ycombinator.com?

There isn't a ton of documentation per-se about HN behavior. There is:

https://news.ycombinator.com/newsguidelines.html

and

https://news.ycombinator.com/newsfaq.html

and a handful of posts by dang, sama, pg, etc. over the course of the years. most of the rest is what long-time users have just figured out through observation. There's a Git repo[1] out there that aggregates a lot of that stuff, but keep in mind that it's technically unofficial. That said, I think most of what's there is widely considered to be correct.

[1]: https://github.com/minimaxir/hacker-news-undocumented

Thanks, that's a good summary of what I've seen referenced throughout my years here.

I can't find any reference to something like "combine the scores of new submissions of the same URL to the first submission's score" though. I guess that's either new information or incorrect.

I can't find any reference to something like "combine the scores of new submissions of the same URL to the first submission's score" though. I guess that's either new information or incorrect.

I think that falls into the "noticed through observation" bucket. I'm relatively sure that it is correct, as I've noticed that behavior myself. But, I have no official standing here and I could be totally wrong. But that sure seems to be what happens in my experience.

So you may have misunderstood your observations, just like I maybe did.

That's absolutely possible. This particular pattern has seemed pretty consistent over the years, but unless somebody from the HN admin crew chimes in, I guess we'll never be 100% sure.

You can try this yourself. Go to the ‘new’ page and submit an existing URL. You’ll be redirected to the existing post which will now have at least one more vote.

which will now have at least one more vote

Not automatically.

What's that even mean? Did you observe something different or are you just arguing?

We use both MemoryStore and normal instances. The latter for a use case where the data is shardable and so we run a redis process on each core and the client picks the right one. It saves a lot of money over using MemoryStore.

It also saves you from Google performing maintenance on the machine and deleting all your Lua scripts.

KeyDB is becoming increasingly popular though.

The biggest problem with Redis, at least in C++ land, is the client libraries. hiredis doesn’t support Redis Cluster, and other 3rd party clients that do are of unknown quality.

I've been using UpStash's serverless Redis offering and it's worked super well for my needs. Scales to zero/free which was nice for getting started, and using their http SDK didn't need to worry about concurrent connection limits when calling from simultaneous cloud functions. & not a second of downtime in the few months I've used it so far.

Want to move more of my app's datastore to Redis now that I've learned more about sorted sets etc.

Reply on news.ycombinator.com