An order's status changed - from 'cooking' to 'on its way'. That has to show on the customer's screen right then, without a page refresh. Normal HTTP cannot do this - in HTTP, the server cannot send anything unless the client asks. The alternative of asking every 5 seconds (polling) is possible, but it is wasteful - most of the time the answer will be 'nothing changed'.
WebSocket - an open telephone line
A WebSocket is opening a connection once and keeping it open - after that, both sides can talk at any time. Socket.io makes working on top of this connection easy: sending messages by event name, handling whose connection dropped, and running on older browsers through a fallback path.
import { Server } from "socket.io";
const io = new Server(httpServer, { cors: { origin: "https://your-frontend.com" } });
io.on("connection", (socket) => {
// The user joins a room of their own name - only they will get their news
socket.on("join", (userId) => socket.join("user:" + userId));
socket.on("disconnect", () => {
console.log("A connection dropped:", socket.id);
});
});
// When an order's status changes, tell only that customer
io.to("user:" + order.userId).emit("order-status", {
orderId: order.id,
status: "on-the-way",
});Rooms - not everyone has to hear everything
A room is dividing into groups. Every user stays in their own room, every chat group has a separate room. When sending a message, you only need to send it to the relevant room - unnecessary messages do not go to the other thousand users. When building a chat, this idea is the backbone: a message arrives on one event, goes only to that room's members, and also gets saved in the database so history can be seen later.
Remember one limit: even if a thousand connections run on one server, when there are multiple servers you have to keep track of who is connected to which server - that needs a Redis adapter (it comes up again in the week 4 chat capstone). And an open connection does not mean trust - who is connecting has to be verified with a token, just like HTTP auth.
The mistake everyone makes
Putting WebSocket in places where real-time is not even needed - where a normal API call would be enough. The opposite mistake also shows up: polling every second and pressuring the server. Another mistake - not verifying auth on socket connections, so anyone can enter someone else's room and listen to messages.
Today's practice
Put Socket.io in your API. When an order's status changes, send an event to that user's room. Connect as two users in two separate browser tabs and verify - is one person's news reaching the other?
How to say it in an interview
Where news has to be sent from the server side at once - notifications, chat, live status - I use WebSocket with Socket.io. With rooms I send messages only to the relevant users, I verify auth with a token at connection time, and with multiple servers I keep the connections in sync with a Redis adapter.