When Apple still had intel chips, I remember how long it used to take for external displays to be properly detected and to start working. The first time I used a M series chip, suddenly the displays were detected and started working in a second or two. I had assumed that that’s how long it always had to take, when in reality it could an order of magnitude quicker, and on a thunderbolt dock.
Rails shops running on normal CRuby, have difficult in effectively scaling out multithreading due to the GVL lock. It's much easier to "scale" ruby using forking with sidekiq or multi process, and to have it consume data from a Redis list. It is possible to get around the GVL using JRuby, but that poses a different set of constraints and issues.
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.
I've got a Apple TV -> Denon -> LG C3. CEC on the appleTV remote will turn all 3 on, and long pressing (power button on appletv remote) will turn all 3 off, not just screen saver with input.
After working with the Postgres WAL through logical replication in the last few months on a work project. My largest gripe is that some specific behaviors (like how a WAL receiver process should respond to a fast-shutdown on the database backend), aren't well documented outside of asking questions on the postgres discord.
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.
I wish postgres would add a durable queue like data structure. But trying to make a durable queue that can scale beyond what a simple redis instance can do starts to run into problems quickly.
Millions of events per day is still in the small queue category in my book. Postgres LISTEN doesn't scale, and polling on hot databases can suddenly become more difficult, as you're having to throw away tuples regularly.
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.
I will be curious to see what JRuby's fiber implementation is like in their upcoming version, currently I work on JRuby rails deployments with dozens of threads across hundreds of nodes. There's definitely some learning curves and tuning necessary when you have 40 threads in contention over a particular shared resource vs 3-5 on regular CRuby.