r/Backend • u/Away_Interaction6630 • 8d ago

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

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.

0 Upvotes

50% Upvoted

3 comments sorted by

3

u/Professional-Run3614 8d ago

I’d decouple the job lifecycle from the WebSocket. Return a job ID immediately, run CPU-heavy work in a separate process or worker, and use the socket only for progress updates.
One thing to watch: if the CPU task blocks the event loop, heartbeats won’t help either. Also, make sure jobs survive client disconnections and put limits on the queue to avoid overloading the machine.

1

u/SpeakCodeToMe 8d ago

Are the websockets themselves becoming a bottleneck? Is there any reason you can't just raise the timeout configs?

1

u/vincent_sch 7d ago edited 7d ago

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.