You could make an incoming WebSocket message behave much like an incoming HTTP request: The DO worker starts running, reads the message, runs any `event.waitUntil` work to completion, and goes to sleep. Let your runtime unload DO workers while holding on to their WebSocket connections.
That would mean maintaining "chatroom" state in memory wouldn't be enough, the DO worker would have to always write it to the durable store, to be safe to unload.
You'd have some sort of a "WebSocket connection ID" that could be used as key for storing state, and when the next message comes in, the worker would use that key to fetch state.
EDIT: And the ability to "rejuvenate" other WebSocket connections from their IDs, so you can e.g. resend a chat room message to all subscribers.
That would mean maintaining "chatroom" state in memory wouldn't be enough, the DO worker would have to always write it to the durable store, to be safe to unload.
You'd have some sort of a "WebSocket connection ID" that could be used as key for storing state, and when the next message comes in, the worker would use that key to fetch state.
EDIT: And the ability to "rejuvenate" other WebSocket connections from their IDs, so you can e.g. resend a chat room message to all subscribers.