[moe]

Our queues are implemented using BLPOP which blocks until items arrive, so no polling is needed.

The newer pub/sub stuff promises to be very useful, too, but we didn't have a use-case for that, yet. Our app generally needs messages to persist until they are consumed.

What I can say however is that none of the concerns we initially had about performance/scalability held any water.

We are still running on a single redis instance (plus a slave) on a moderately sized server and it happily processes 100 messages/sec average between 4 producers and a varying number of consumers (20-100).

To add insult to injury our monitoring metrics show that this isn't even a worthwhile load for redis. The server is nowhere near breaking a sweat, the CPUs barely drop below 90% idle, there's no disk i/o to speak of, and the memory usage is more than reasonable (plenty headroom for our purposes).

Thus "just throw it at redis" has long become a common stopgap meme in this particular project. And so far we didn't have to replace any of these supposed stopgaps with something else.

[StavrosK]

Ah, very nice. It seems that I shouldn't have any qualms about throwing redis at most of my problems then, thanks!

[catch23]

in case you're wondering, we use a simple queueing thing called redpack:

https://github.com/luxdelux/redpack