Si desea una respuesta muy general, diría que puede o no querer preocuparse en este nivel. No tienes que hacerlo.

En este caso específico, la API original es reactiva (inmediatamente devuelve Mono ), lo que significa que el trabajo real no se realizará en el subproceso que llama a callMongoReactive / findSomething , sino en cualquier grupo de subprocesos que mongoDB decidió usar para respaldar este Mono . Esto significa que la elección del despachador en este caso realmente no importa.

Entonces, especialmente en este caso, optaría por la opción más simple: no elegir. Use coroutineScope y exponga una función de suspend para que la persona que llama decida sobre el contexto de la rutina (incluido el despachador):

 suspend fun queryInParallel(parameters: List<Param>): List<Result> = coroutineScope { parameters .map { async { mongo.findSomething(it).awaitSingle() } } .awaitAll() }

Este es el idioma habitual para "descomposición paralela del trabajo". Yo diría que es el más común.

¿Cuál es la estrategia óptima de uso de los despachadores de rutina que hace que estas solicitudes asíncronas se ejecuten en paralelo simultáneamente?

Vale la pena señalar que el idioma anterior expresa concurrency , pero si los cuerpos de los async se ejecutarán en paralelo o no depende del despachador elegido por la persona que llama.

(Para reiterar, el despachador solo afecta el cuerpo de esos asíncronos, y en este caso específico no usan tanto el hilo porque llaman a un método sin bloqueo de todos modos, por lo que realmente no importa).

Ahora, en los casos en los que importa , cualquier despachador respaldado por más de 1 subproceso permitiría el paralelismo aquí. Hay varios despachadores existentes que pueden ser útiles, sin necesidad de crear su propio grupo de subprocesos. Dispatchers.Default tiene una cantidad de subprocesos adaptados a la cantidad de núcleos de la máquina en la que se ejecuta, por lo que es una buena opción para el trabajo vinculado a la CPU. Dispatchers.IO escala la cantidad de subprocesos según sea necesario, lo cual es útil si tiene muchos bloqueos de IO y desea evitar la inanición.

También puede usar el limitedParallelism en cualquier despachador para obtener una vista con solo un número limitado de subprocesos, lo que puede ser útil en algunos casos en los que no desea crear un grupo de subprocesos adicional, pero sí desea limitar el número. de subprocesos disponibles más de lo que ofrecen los despachadores incorporados.

Crear un grupo de subprocesos personalizado puede ser interesante si desea aislar partes de su sistema en caso de que un subsistema se comporte mal y prive de subprocesos. Sin embargo, tiene una sobrecarga de memoria, ya que está creando más hilos.