Multi-threading paradigm for handling express requests

Now what i request below some may find it weird, but i have my reasons so bear with me..

I am using node.js with express and the default behaviour of it is to serve requests concurrently using single thread works fine for most of the cases.. but not mine so the ask, Is there any library/middleware for express which will use worker thread concept and serve 1 request per thread?(old way of doing things)

Reasons:
My request processing consists of 2 things mainly talk to Redis/SSD(IO bound 1 sec) then do CRC, Unzip, Zip(compute bound 4sec) problem is when parallelism is high, node async single thread approach starts elongating request time as more parallel request starts to hit the server, thus making response time unpredictable or timming out alltogether(also saturation of eloop cause of sync work) so this ask..

What i have tried: 1) Cluster mode should have same effect like threads the only downside is "memory" consumption, I have app level in process cache in cluster mode all cluster child process have ideal copy of it thus shooting up mem req..
2)Piscina which offers something simillar for next framework but not sure since i am using express..

So finally the ask is simple we already have implementation for how we can use single thread async operations for get set db kind of rest services.. i am asking for the opposite implementation or the old school way of handling requests. A ready to use library/middleware if any..

Nodejs clustering is the pre-built way to involve more than one CPU in the processing of your Express requests. I'm not aware of some other pre-built mechanism for nodejs/Express.

You mentioned that you think that uses too much memory, but nodejs threads aren't going to be much more memory efficient since they start up a separate VM interpreter for each thread themselves. If you have a specific memory requirement, then please share it.

From what you've described, the CRC and compression are the CPU-bound pieces. The I/O stuff will likely work just fine in the main thread since it's non-blocking and not CPU-bound.

So, you could create a job queue that is handled by multiple threads and then feed the compression and CRC work to the job queue. This would keep your main web server thread free and responsive for other requests while using multiple CPUs for the CPU-intensive work. The main thread would put requests into the queue and each worker would grab a job, work on it, return the result back to the main thread where the main thread could then send the response, then the worker would grab the next item from the job queue. It's not much code to write your own queue (I've written several myself) or there are many third party libraries that offer queues with various features.

Usually, I code the workers to just respond to a job sent to them. The queue knows about the workers and whenever it gets a new job, it checks to see if it has an idle worker. If so, it sends it the new job. If not, it adds the job to the queue and waits for an existing worker to finish the job it's working on.