I'll probably skip the Redis for now, it's unlikely that I'll need >1 instances for a long time and if that time arrives, I'll review it again, hopefully with more resources. This system requires too much plumbing if you want it to be resilient without human intervention.

All the stuff I don't want to deal with at the moment:

• Redis pub/sub topic keyspace has to be sharded manually if you need >1 Redis instance
  • You need to create a library that picks correct Redis instance based on topic name and list of available IPs (search forhashring), you need to use the same library everywhere you want to subscribe or publish to pub/sub system
  • Where do you store the list of available Redis IPs? Hardcode? Then you have to deploy your whole backend and Redis instances at the same time. Another Redis? It has to be resilient as well. Durable cloud database like DynamoDB? Probably your best bet
• If you need to reshard Redis instances (e.g you're adding or removing an instance)
  • all subs/connections have to dropped (good luck with thundering herd)
  • ws servers have to fetch the list of new Redis instances and resubscribe all connections to correct instance (hashring)
• WS instances have to ping connected Redis instances and if down, A) switch to replica B) do previous 2 points again

I doubt this is the complete list of cases you have to handle and maybe there are easier ways to handle this.

I'm not sure if any of the open source proxies support pub/sub use case, e.g twemproxy or envoy.

That sounds a lot like an "Edge database" (which is a buzzword). I swear - all databases are essentially the same very thing. Only slight variations in what they optimize for (transactions or analytics). The rest is marketing fuzz and of course more or less good implementations.

@alexhultman We know that Node.js is trash for you, but what do you think about Redis, is not trash?

Redis is fine. In my I/O benchmarks with pub/sub it beats all contenders by far (tested probably 12 MQTT servers). Mosca, the one written by Matteo in JavaScript was by far the slowest.

If you look at the commit stats of redis you can see 99% is written by one guy under one company - I think that's important for keeping on track with what you aim for. Nodejs on the other hand is written by so so many different people with conflicting vision, competence and feel for quality.

Nodejs doesn't even screen for competence anymore (did they ever?) - if you have purple enough hair you're free to hack on things you have no idea about

I kind of agree with that. Products can be messy, rushed and clued together Frankenstein monsters because sometimes it's more important to deploy the feature (retain a high profile client, etc) instead of saving $500 optimizing the code and decrease the hardware requirements.

I think good tools shouldn't have that luxury. But the range of quality, focus, etc comes with the open source territory.