It always comes back to the database, doesn’t it?

I thought XMPP allows you to hold session/presence in memory. If you go down, you just re-establish the session and ask for presence information again. Not so?

Where XMPP is operationally hard is when you have a lot of clients (50,000+). HTTP LBs don’t work well for that at all, and become bottlenecks on open connections. The only answer seems to be to get said LBs off the path. Which puts us back to about 1996, the web’s stone age, and begs the question – how to tell a client to bind to a node in the cluster without pushing load balancing logic down to the client and exposing your server topology? DNS SRV isn’t the complete answer; good for federations, not so much for clustering. Also even if you could figure out binding, the XMPP stacks themselves don’t seem to have clustering entirely figured out (openfire and djabberd possibly being further along there). I’ve been surprised at where some highly performant servers start to buckle.

And here’s the kicker – if a cluster communications swarm doesn’t kill you, the database writes quickly start to dominate how many people can connect, and well before sockets management does. All the stacks I’ve seen are writing on connection (to setup presence and sessions). So, Yet Another Database Scaling Problem, and around we go.