The Compose View - The Million User Webchat?

We're all about databases at Compose and that means we see a lot of interesting articles about databases. The Compose View is a new space on the blog where we'll share some of those with you and tell you what we think about them. So without further ado…

Million user webchat with Full Stack Flux, React, redis and PostgreSQL

Following on from discussing how to make a 1000 user chat system, Nexus Flux creator Elie Rotenberg has been considering what it would take to scale to a million user chat. Starting with the websocket server from the previous demo, Elie steps through the scaling problem.

First he introduces PostgreSQL as a single source of truth at the backend, behind the the websocket server on the basis that you can use dispatch actions with stored procedures and
NOTIFY clients of the database of updates. PostgreSQL talks to a Flux/Node.js based intermediate layer which talks onwards to the clients.

Then, to push for scale he introduces a back end multiplexer to reduce the load on the intermediate layer. This involves using Redis as a message queue in a business logic multiplexer, with Redis/SQL clients moving messages between the PostgreSQL database and the message queue and the intermediate layer running Redis clients to feed the web clients.

With the architecture defined and experience of implementing a similar architecture with tens of thousands of users, Rotenberg goes on to estimate the amount of processing power that would be needed to service that million users.

The Compose View: We like theoretical architecture exercises as much as the next guy. This approach coincides with how we see databases at Compose. Each database technology brings something valuable to the stack; in this case, the solid foundation of PostgreSQL and the fast, sleek message queue capabilities of Redis. Whether it'd actually work at the million user scale is a different question. There's a lot of moving parts in the design which could be replaced by a messaging system with websocket support and attaching the database infrastructure to that messaging system.

Still, it's a much better theory than say trying to turn PostgreSQL into an in-memory database, or as it's called in this Database Soup article "Running with scissors mode".