(Real-Time) Jul 2026 — Present · Webbrains Technologies
Live study rooms that stay in sync, however many people join.
Virtual study rooms with live focus timers, streaks, badges and leaderboards. Everyone in a room sees the same thing at the same moment — and it stays that way as more people join.
(01) In numbers
Sessions, groups, tasks and scoring
The durable half of a mostly live product
Node-Cron: reports, reminders and summaries
Fanned out over Redis, not pinned to one box
(02) Under the hood
01 · CLIENT
A participant joins a room and expects the count to be right — not eventually right, and not right only for whoever landed on the same server.
02 · EDGE
The proxy passes the connection through as a WebSocket rather than terminating it as a request.
03 · SOCKET
One of several Node processes accepts the connection. Which one it was should stop mattering immediately after this.
04 · ADAPTER
The adapter carries emits between processes. A room is a room across the whole cluster, not per instance.
05 · API
The REST surface behind the live layer: sessions, groups, tasks and scores, over 15 Mongoose models.
06 · QUEUE
Anything slow is handed to a queue instead of being done on the socket's thread. The live layer stays live.
07 · CRON
Node-Cron jobs for the work that has a time rather than a trigger — summaries, reminders, and the periodic tidying.
(03) The story
01 — The Problem
A participant count kept in memory is right until there are two servers, and then it is two different numbers. Leaderboards have the same shape of problem: everybody in the room has to be looking at the same figure.
02 — What I Built
Socket.IO runs over a Redis adapter so an emit reaches every process. The expensive work moved off the socket path into BullMQ workers, and anything that runs on a clock moved into Node-Cron.
03 — What Changed
Adding a process adds capacity instead of adding a version of the truth. A participant sees the same count as everyone else in the room, regardless of which instance answered them.
(04) Architecture
01
Browser sessions holding a socket open as well as making requests.
02
Nginx passing WebSocket upgrades through to the Node processes.
03
Socket.IO over a Redis adapter: rooms that span processes.
04
Express modules for sessions, groups, tasks and scoring.
05
BullMQ workers, and twelve Node-Cron schedules.
06
15 Mongoose models, with Redis carrying the state that is only ever live.
(05) Decisions
The moment there are two instances, in-memory room state is two answers to one question. Redis holds it so the processes stay interchangeable.
Work that takes a while goes to BullMQ. The socket layer's job is to be quick, and the most reliable way to keep it quick is to give it less to do.
Twelve cron jobs run the periodic work, rather than it piggybacking on whichever request happens to arrive at the right moment.
(06) Built with
A live layer that does not care which process answered.
For the technically curiousSocket.IO over a Redis adapter, so real-time scales past one Node process. Live participant counts and leaderboards that had to stay correct while running on more than one Node process. Socket.IO over a Redis adapter now scales the real-time layer horizontally, with the heavy work moved into BullMQ queues and twelve Node-Cron jobs.
Node.jsExpressSocket.IORedisBullMQNode-CronMongoDBMongooseReactDockerNginxPM2