Case study — 08
Scalable Notification System.
Notifications that keep flowing when the WebSocket layer scales out — because no single server owns delivery.
- Role
- Open source · author
- Type
- Open source
- Stack
- TypeScript · Redis · WebSockets · Docker
01
The problem
A single WebSocket server can push a message to anyone connected to it. Run two, and a notification only reaches users on the server that happened to receive the request. Delivery has to work no matter which instance a user is connected to.
02
Architecture
Three services: an API server, a worker and a WebSocket server. A notification flows Client → Server → Redis queue → Worker → Redis Pub/Sub → WebSocket server → Client.
The API only enqueues and returns. The worker blocks on the queue with brPop and publishes each job, and every WebSocket server subscribes, so any instance can deliver to the users connected to it.
03
Targeting
One endpoint handles three message types: private (one user), room (everyone who joined a room) and broadcast (every connected client). Clients identify themselves and join rooms when they open the socket.
04
How it was built
TypeScript services with Redis for both the queue and Pub/Sub, run together with Docker Compose and hot reload for local development. Delivery acknowledgements and a front-end client are next.