Comment lanceriez-vous trois appels distants indépendants en même temps et combineriez-vous les résultats ?

Soit vous les soumettez à un executor de threads virtuels et vous joignez les résultats, soit vous les composez avec CompletableFuture en utilisant supplyAsync sur un executor explicite et allOf pour attendre. Posez un délai d'expiration sur l'opération combinée, traitez l'échec partiel de façon délibérée, et annulez les autres appels quand l'un échoue. La concurrence structurée avec un task scope exprime exactement cette forme et lie la durée de vie des sous-tâches au bloc, même si l'API est encore en preview.

Avec les threads virtuels c'est devenu simple : j'ouvre un executor qui crée un thread par tâche, je soumets les trois appels, puis je joins chaque future. Ça se lit comme du séquentiel, mais les appels se chevauchent, et chacun a son propre délai d'expiration client. Sur une base de code plus ancienne j'utilise CompletableFuture avec supplyAsync, et je passe toujours mon propre executor, parce que celui par défaut est le ForkJoinPool commun, dimensionné pour du travail CPU et partagé par tout le processus. Ensuite allOf pour attendre, et un délai d'expiration sur la future combinée pour qu'une dépendance bloquée ne retienne pas la requête indéfiniment. La partie à laquelle je réfléchis le plus, c'est l'échec partiel : si l'appel aux recommandations échoue, est-ce que je fais échouer toute la page ou est-ce que je l'affiche sans elles ? En général la réponse est de dégrader, donc cette future reçoit un handler exceptionally qui renvoie une liste vide, tandis que les appels essentiels propagent l'erreur. La concurrence structurée exprime bien mieux tout ça, puisqu'un scope joint toutes les sous-tâches et annule le reste quand l'une échoue ou que l'échéance passe, et je l'utilise là où une API en preview est acceptable.