Phase 11Days 118-124

Real-Time Systems with Socket.io

WebSockets, chats, group chats, and live collaboration — built and scaled

Phase Goal

Move past request/response. Build the real-time layer that powers chat, group chat, presence, typing indicators, and live collaboration — then scale it horizontally the way production apps do.

Progress

Notes

Open the written lectures for this course before checking off the phase topics.

Mini Projects

Harbor Berth Alert

Wildfire Resource Map

Projects

Live Emergency Drill Map — DEPLOYED

Day 118: WebSockets & Socket.io Fundamentals

The core problem: HTTP is client-initiated — the server cannot "push"Polling vs long-polling vs WebSockets — latency and cost trade-offsReal features that need a live channel: chat, notifications, presence, live dashboardsWhen you should NOT reach for WebSockets (simple CRUD, infrequent updates)

One TCP connection, kept open, full-duplex (both sides send anytime)The HTTP Upgrade handshake: 101 Switching Protocolsws:// vs wss:// (TLS) — why wss in productionFrames, not requests — no headers per messageWhat the browser gives you: the native WebSocket API (and its rough edges)

What Socket.io adds: auto-reconnect, fallbacks, rooms, acks, namespacesThe trade-off: it is NOT raw WebSocket (custom protocol, needs its client)When raw ws is the right call (tiny footprint, non-JS clients)Install: socket.io (server) + socket.io-client (browser)

Attach io to an existing HTTP/Express serverio.on("connection", socket => ...) — the connection lifecyclesocket.emit / socket.on — sending and receiving named eventsClient: io(url), socket.on("connect"), socket.emitCORS config for the handshake (the #1 beginner blocker)

Callback acks: emit with a function, server calls it backTimeouts on acks — do not wait foreverWhen acks beat fire-and-forget (did the message actually save?)

Server pushes a "notification" event to connected clientsClient renders a toast + increments an unread badgeDeploy check: open two tabs, trigger from one, see it in both

Mini Project

Harbor Berth Alert

A minimal real-time build shipped on day one: a dispatcher changes a berth assignment, subscribed browsers react instantly, and the learner proves the round-trip before rooms and auth.

Day 119: Rooms, Namespaces & Broadcasting

socket.join(room) / socket.leave(room)A room is just a label — a socket can be in manyPer-user room (user:123) for targeted pushesPer-resource room (doc:abc, chat:xyz) for shared updates

socket.emit — only this socketio.to(room).emit — everyone in a room (including sender)socket.to(room).emit — everyone in a room EXCEPT senderio.emit — every connected client (use sparingly)Choosing the right target to avoid echo/double-render bugs

io.of("/chat") vs io.of("/admin") — logical separation on one connectionNamespaces vs rooms — when each is the right toolMiddleware per namespace

Track online users in memory (Map of userId → socketIds)A user can have multiple sockets (tabs/devices)Emit presence changes to interested rooms

The "disconnect" event and its reasonsRemove the socket from presence mapsOnly mark a user offline when their LAST socket leaves

Day 120: Authentication & Reliability

Pass a token in the handshake auth payload (not a query string)io.use(middleware) — verify the JWT on connect, attach the userReject unauthenticated connections earlyWhy cookies + WebSockets need CORS credentials configured

Verify the user may join THIS room before socket.joinNever trust client-supplied userId — read it from the verified tokenGuarding emit handlers (can this user post to this chat?)

Auto-reconnect with backoff (built in) — and how to observe itconnect / disconnect / reconnect events on the clientRe-joining rooms after a reconnect (state is not automatic)

At-most-once by default — messages can be lost on a dropconnectionStateRecovery for short disconnectsPersist first, then emit — DB is the source of truthsocket.on("error") and server-side try/catch in handlers

Day 121: Build a 1:1 Chat

Conversation (participants[]) + Message (from, to, body, status, createdAt)One room per conversation (conv:<id>)Indexes for fast history queries (conversation + createdAt)

Client emits "message:send" with an ackServer validates → saves to Mongo → emits "message:new" to the roomOptimistic UI: render locally, reconcile on ack (temp id → real id)

States: sent → delivered → readEmit "message:delivered" when recipient socket receives itEmit "message:read" when the conversation is open/visibleUpdate status in DB and broadcast the change

Throttled "typing:start" / "typing:stop" (do not spam on every keypress)Show "online" / "last seen" from the presence layerClean up typing state on disconnect

Per-conversation unread counterPaginated history load (cursor by createdAt/_id)Mark-as-read clears the badge and emits a receipt

Day 122: Group Chats

Group (name, members[], admins[]) — a room per groupJoin/leave changes membership AND socket roomsRoles: admin vs member (who can add/remove/rename)

io.to(group:<id>).emit for one write → many readersMembers offline now must still see it later (persist!)Cost of fan-out as groups grow — where queues/Redis come in later

Unread count per group per user@mentions create a stronger notificationLast-read pointer per member

Who is online in this group"X and Y are typing…" aggregationJoin/leave system messages

Cursor-based infinite scroll (never OFFSET on chat)Loading older messages without losing scroll positionDeleting/editing messages and broadcasting the change

Day 123: Live Collaboration Beyond Chat

Shared state + presence, not just messagesLive cursors, selections, and "who is here" avatarsExamples: Figma, Google Docs, Notion, a shared whiteboard

Emit cursor position (throttled to ~20-30/sec max)Render other users' cursors with name + colorInterpolate for smoothness; drop stale cursors on disconnect

Broadcast granular changes, not the whole documentDebounce/throttle high-frequency editsOptimistic local apply → broadcast → reconcile

Why two edits at once corrupt naive stateLast-write-wins: simple, lossy — when it is acceptableWhat OT and CRDTs solve (Yjs) — named, not implemented hereChoosing the simplest model your feature can tolerate

Shared sticky-notes / cursors board in a roomPresence avatars + live cursorsLast-write-wins on note text for now

Mini Project

Wildfire Resource Map

A shared real-time map where coordinators place resource markers, see presence/cursors, and reconcile last-write-wins status updates—proving collaboration patterns beyond chat.

Day 124: Project — Live Emergency Drill Map

In-memory rooms/presence break across multiple instancesA user on server A cannot reach a user on server BVertical limits: connections per process, memory, CPU

Redis pub/sub as the message bus BETWEEN instances@socket.io/redis-adapter: emits reach sockets on any nodeWhat it does NOT solve (presence still needs shared storage)Deep dive lands in the Redis & BullMQ phase

Why the HTTP long-poll fallback needs sticky sessionsConfiguring sticky sessions on Nginx / a load balancerWebSocket upgrade headers through a proxy

Pusher / Ably / Supabase Realtime — skip the opsCost vs control trade-offMigration path: your event shapes stay the same

1:1 + group chat with presence, typing, read receiptsAuth in the handshake, authorization per roomRedis adapter for horizontal scale (Upstash)Deploy; demo two browsers across the network

Capstone

Live Emergency Drill Map — DEPLOYED

Build a real-time drill coordinator: controllers open an exercise, wardens report zone status, observers submit timestamped incidents, authorized participants see a live map, and the controller closes and exports the drill. Use authenticated Socket.io rooms, presence, acknowledgements, rate limits, Redis scaling, and reconnect recovery.

Room roles, presence, reconnect handling, and host-controlled session states.
Live submissions with rate limiting and a shared board rendered from socket events.
Redis adapter, delivery acknowledgement, and an end-to-end multi-browser demo.

Phase Complete!

After this phase, you'll be able to:

WebSocket protocol + Socket.io: connection lifecycle, events, acks
Rooms, namespaces, and correct broadcast targeting
Authenticated sockets (JWT handshake) + per-room authorization
1:1 chat with persistence, receipts, typing, presence, unread
Group chat with membership, fan-out, and pagination
Live collaboration (cursors, shared state, conflict trade-offs)
Horizontal scaling with the Redis adapter + sticky sessions

You can build and scale the real-time layer behind chat and collaborative products — the feature set that separates a demo from a platform.

Back to all phases

Phase Goal

Day 118: WebSockets & Socket.io Fundamentals

Why request/response is not enough

The WebSocket protocol & upgrade handshake

Socket.io vs raw ws

Your first Socket.io server + client

Acknowledgements (request/response over sockets)

Ship: live notification bell

Harbor Berth Alert

Day 119: Rooms, Namespaces & Broadcasting

Rooms — the core targeting primitive

Broadcasting patterns

Namespaces

Presence basics (who is online)

Disconnect & cleanup

Day 120: Authentication & Reliability

Authenticating the socket

Authorization per event

Reconnection & the client lifecycle

Delivery guarantees & error handling

Day 121: Build a 1:1 Chat

Message & conversation schema

Send, persist, deliver

Delivery & read receipts

Typing indicators & presence

Unread counts & history

Day 122: Group Chats

Groups & membership model

Fan-out to many members

Per-room unread & mentions

Member presence & typing in groups

History pagination at scale

Day 123: Live Collaboration Beyond Chat

The collaboration mental model

Live cursors & selections

Syncing shared document state

Conflicts: last-write-wins vs CRDT/OT

Build: a live collaborative board

Wildfire Resource Map

Day 124: Project — Live Emergency Drill Map

Why one Node process is not enough

The Redis adapter (from scratch)

Sticky sessions & load balancing

Managed real-time (when to buy vs build)

Build, test, and deploy the facilitation room

Live Emergency Drill Map — DEPLOYED

Phase Complete!