TransactionCoordinator runs tasks on the fixed executor and the fixed executor has the behavior where it'll spawn a new thread to execute the task if an idle thread isn't already available. This behavior is important for the liveness of the system because it prevents tasks which would unblock other operations from being delayed indefinitely. However the truly urgent portion of the TransactionCoordinator starts from when the prepareTransaction command is issued to the participant shards through the last participant shard having responded to the commitTransaction xor abortTransaction command. The other portions of the TransactionCoordinator are not time-sensitive because they don't acutely impact the success of concurrent read and write operations.

george.wangensteen@mongodb.com suggests taking a further step back from the issue of spawning too many threads and modeling the TransactionCoordinator as a series of queues whether work passes between these queues and there are different thread pools and policies for processing the work in these queues.