Let's design a worker pool for CPU-bound jobs. What decisions do you actually have to make?
Strong candidates make saturation behavior an explicit decision someone signed off on, and watch queue wait time before any other health signal.
You size the pool around the number of CPU cores, and you reuse workers instead of spawning one per task, since that amortizes the startup cost. Then you put a queue in front so tasks can wait when every worker is busy. Each task goes out to a free worker with postMessage and the result comes back the same way. When it saturates you either queue with a limit, reject new tasks, or push backpressure up to the caller. You want per-task timeouts too, so a stuck task doesn't hold a worker forever, and you restart workers that crash. Honestly, libraries like piscina package most of this up already, the sizing, the queueing, the timeouts, so hand-rolling it is rarely necessary. And you watch queue depth and task latency to tell when the pool is undersized.