Home
Feed

Extend

Hashnode Pro
Hashnode for Agents

Resources

The foreword
Hashnode gql skill

Buildful - AI coding agent that delivers frontier-level results at a fraction of the cost Bug0 - The AI-native e2e QA regression testing Hackathons Changelog Brand @hashnode on X Hashnode on LinkedIn Support - hello+support@hashnode.com Code of Conduct Terms Privacy Sitemap

Search Hashnode

Search posts, tags, users, and pages

Feed/

Discussion

I Built a Real-Time Collaborative Whiteboard to Understand Stateful Backends

I built a real-time collaborative whiteboard to understand WebSockets, stateful backends, room state, broadcasting, and persistence.

Sep 4·11 min read·newsletter.anshumancdx.xyzRead the article

#websockets
#nodejs

#turborepo

Written by

Anshuman Praharaj

@anshcds · India

View profile

coffee and goofy ah code

Mostly MERN and Python Currently learning CS concepts and building things.

Responses4

Markdown supported · ⌘↵ to post

Julian Neagu

Sep 5

the part about state clicked for me too. building the room map makes the whole websocket flow much easier to reason about

Raunak Singh

Sep 5

Splitting HTTP auth and history from WebSocket broadcast makes the architecture easy to follow. The next scaling challenge would be moving room membership out of a single process. Are you planning Redis pub/sub or sticky sessions first?

Anshuman Praharaj

Sep 5

yes will using pub/sub for scale is ofc the next thing

Raunak Singh

Nice. Redis pub/sub is a natural next step. I would keep room state behind a small adapter so you can compare in-memory and Redis implementations without changing the WebSocket handlers. That should make the scaling path easier to test.

Sep 16