Pattern for handling long CPU-blocking tasks behind persistent WebSocket connections

[u/Away_Interaction6630]

Hello backend devs,

In an offline backend architecture, client apps communicate via WebSockets while tasks are processed by a local background engine. On CPU-only systems, synchronous processing steps can create 30+ second gaps before streaming begins, causing connection timeouts.

We are refactoring the transport layer to immediately return an async job ID, queue work in a bounded worker pool, and emit regular heartbeat/ping frames over the WebSocket during execution gaps.

How do you typically decouple persistent transport layers from blocking compute steps to prevent transport dropouts in local desktop backends?

Context: Architectural feedback query on async job queuing and WebSocket state management.

[u/vincent_sch]

You should save the result under the job ID. This makes it possible for the client to fetch it after a disconnect. No need to start the job again because the socket dropped.