My app uses websockets (live updates, chat, notifications, presence) and it works in development. I haven't thought about what happens at real scale or across multiple server instances. Audit my websocket layer for production readiness: 1. Connection lifecycle: do clients reconnect with backoff (and jitter) when the connection drops, or does every client retry instantly in sync when the server restarts, creating a thundering herd? Do abandoned connections get cleaned up server-side with heartbeats/ping-pong and idle timeouts? 2. Memory per connection: what state do I hold per connected client? Subscriptions, buffers, and user objects held in memory leak slowly as connections churn. Check that disconnect handlers actually remove everything they added. 3. Multi-instance delivery: if I run more than one server process, a message produced on instance A won't reach clients connected to instance B unless there's a shared pub/sub layer (Redis or equivalent). Check whether my setup handles this or silently breaks when I scale past one process. 4. Message volume: am I broadcasting everything to everyone, or scoping messages to rooms/channels/users? Check payload sizes too; sending full objects on every change doesn't scale. 5. Degraded behavior: what does the UI do when the socket is down? If live updates silently stop, users act on stale data. Add a visible disconnected state and a catch-up refetch on reconnect. 6. Deploys: what happens to open connections during a deploy? Clients should reconnect cleanly, and the server should drain connections gracefully rather than dropping thousands at once. Don't add Redis pub/sub if I'm genuinely single-instance and will stay that way; flag it as a scaling prerequisite instead. The deliverable is the audit findings per area, the fixes for what's broken now, and a clear note on what becomes mandatory at which scale.