I assume the plan is to host it on EC2, meaning that existing EC2 users can access it with very low latency.

That's how these cloud infrastructure providers work, right?

That's correct, it's hosted on EC2. We plan to host other instances on different cloud providers, to the same effect.

Ah makes sense - Latency ought to be fine in the same availability zone.

I can see this being incredibly useful for some use cases of redis (pub-sub maybe). There are of course others, such as using redis as a memcache replacement, where latency is going to be a much bigger issue...

That's a good idea if I understand it correctly. That is, taking a Redis instance, modifying it in some way so that Pub/Sub supports authentication (probably this means creating an HTTP wrapper?) and then you have a inter-cloud messaging system that is similar to "twitter for computers".

Actually, I was just suggesting that using commands like PSUBSCRIBE, PUBLISH are probably "high-latency" safe, because the general use cases (job queues, delayed writes, real-time web) for that are "soft realtime."

High latency won't mesh well in a situation where you need to do 100s or 1000s of writes at per request, or 100s of reads at a time, and so a hosted service seems less ideal to me for those situations.

Maybe my outlook on this is wrong, or I'm misinformed.

EDIT: catching up on other threads, it seems as though latency will be less an issue since they'll host on EC2, or Rackspace Cloud, or wherever demand is needed. That's smart, and not something I initially thought of.

I should dust off my NodeRed project from last year. It provided a neat pubsub system for node.js and redis.