2,507 karma · joined February 28, 2018
github @skunkworker
I work in ruby, go and postgres.
Is the Xbox 360 (Xbox 2) vs PS3 debacle all over again.
There is some definite blending of async messaging in the Ruby world though. I've seen connectors which take protobufs on a kafka topic and use sidekiq to fan out the work. With Redis (looking at sidekiq specifically) it becomes trivial to maintain the "current" working set with items popped out of the queue, with atomic commands like BLMOVE (formerly BRPOPLPUSH).
Kafka is taking an interesting turn however with the KIP-932 "Queues for Kafka" initiative. I personally believe it could eat RabbitMQ's lunch if done effectively. Allowing for multiple consumers, a "working set" of unack'ed data, without having to worry as much about the topic partition count.
PayPal Honey extension has again "featured" flag in Chrome web store - https://news.ycombinator.com/item?id=43298054 - March 2025
LegalEagle is suing Honey [video] - https://news.ycombinator.com/item?id=42581108 - Jan 2025
uBlock Origin GPL code being stolen by team behind Honey browser extension - https://news.ycombinator.com/item?id=42576443 - Jan 2025
Show HN: Open-source and transparent alternative to Honey - https://news.ycombinator.com/item?id=42535274 - Dec 2024
Exposing the Honey Influencer Scam [video] - https://news.ycombinator.com/item?id=42483500 - Dec 2024
Amazon says browser extension Honey is a security risk, now that PayPal owns it - https://news.ycombinator.com/item?id=22016031 - Jan 2020
copied from this comment https://news.ycombinator.com/item?id=43538687
Specifically: If the server requests a reply on a heartbeat, the status update should include the heartbeat's LSN on the next loop. But a standby status update includes the LSN values + 1.
I was able to get it working and properly disconnecting to a fast shutdown, but when you get into the internals of the logical WAL receiver loop, it can get nuanced.
And my largest compliment is that the Postgres discord is filled with some extremely knowledgeable and helpful people. I was able to figure out some really specific and nuanced behavior around the different status messages being sent to the primary server, thanks to the in-depth responses there.
Also, LISTEN/NOTIFY do not scale, and they introduce locks in areas you aren't expecting - https://news.ycombinator.com/item?id=44490510
10 message/s is only 860k/day. But in my testing (with postgres 16) this doesn't scale that well when you are needing tens to hundreds of millions per day. Redis is much better than postgres for that (for a simple queue), and beyond that kafka is what I would choose in you're in the low few hundred million.
https://kinexon.com/products/kinexon-rtls was what was used.
Source: I picked up a 6 month supply last week.