Is having a single threadpool better design than multiple threadpools

The purpose of having separate dedicated threadpools is so that an activity doesn't get starved for threads because other activities took all the threads. If some service has its own threadpool then it is assured of having a certain number of threads at its disposal and it's not as sensitive to demands made by other services.

With the multiple dedicated threadpools if a service needs too many threads then it has to wait for threads to be available, introducing back-pressure into the system so that it degrades gradually, and since other parts have their own thread pools they have a chance to catch their parts up. So the idea is that the system should have more stable characteristics as load changes. In the case you describe having a separate threadpool for scheduled tasks makes sure that those tasks get run regardless of how busy the rest of the system is.

The multiple threadpools would require tuning to make sure each pool had enough threads and not too many. With a single threadpool you wouldn't need the tuning and might make better use of all the threads sometimes, but you might not have the predictability of knowing some important task would get the threads it needed to finish in a timely manner.

Having a single thread pool is NOT a good design because in case of 1 thread pool, if one part of the application becomes slower, threads will concentrate there. If proper timeouts are not implemented, threads will stay and consume resources. A lot of such threads and connections can cause our system to break as no threads will be left for new requests.

On the other hand, having multiple thread pools ensures that issue is contained and does not become a system-wide failure. We can have different thread pools for accepting connections, running batch jobs, talking to remote api's databases. It does reduce efficiency to some extent but makes our system robust and fault tolerant.