Cartographier les traitements et leurs contraintes

Une requête qui attend la génération complète d’une facture immobilise une réponse HTTP et peut finir par expirer. Un export volumineux peut, lui, consommer trop de mémoire s’il est traité d’un seul bloc. Dans cette leçon, vous cartographiez les traitements du service de commandes pour savoir lesquels doivent répondre immédiatement et lesquels peuvent être séparés de la requête.

Partir du parcours d’une requête

Le chemin critique d’une requête regroupe les opérations que le serveur doit terminer avant de pouvoir répondre au client. Pour une demande de création de commande, il peut inclure la validation des données, l’enregistrement de la commande et la réponse indiquant son résultat. Plus ce parcours s’allonge, plus le client attend et plus une panne d’une dépendance peut empêcher la réponse.

Un traitement synchrone se déroule dans ce parcours : l’appelant attend que l’opération soit terminée pour obtenir son résultat. C’est adapté aux étapes courtes dont le résultat est nécessaire immédiatement, par exemple vérifier qu’une commande existe avant de la modifier. Un traitement asynchrone est lancé sans obliger la requête à attendre sa fin ; cette approche convient notamment à la génération d’une facture, qui peut durer ou échouer indépendamment de l’enregistrement de la commande.

Comparer durée, volume et tolérance aux échecs

Pour chaque opération, relevez sa durée habituelle et sa durée lors d’un pic, le nombre d’éléments traités et ce qui se passe en cas d’échec. Une facture unitaire peut être assez rapide en temps normal, mais rester variable si elle dépend d’un service externe. Un export de nombreuses commandes peut durer longtemps et produire un résultat volumineux : le transférer en une seule réponse exige donc une analyse distincte, abordée dans le module consacré aux streams.

La tolérance aux échecs ne signifie pas qu’une opération peut échouer sans conséquence. Elle décrit ce que le service doit garantir quand un incident survient : refuser proprement une écriture incomplète, préserver une demande de facture pour pouvoir la reprendre, ou interrompre un export dont le client s’est déconnecté. Une exigence de disponibilité précise quelles opérations doivent rester accessibles malgré une panne ; une exigence de reprise précise comment retrouver un fonctionnement correct après cette panne.

Rendre les critères vérifiables

Une cartographie utile remplace les impressions par des observations. Mesurez la durée sur des requêtes représentatives, notez le volume maximal attendu et identifiez les dépendances externes. Les valeurs ci-dessous sont des exemples de classement, pas des seuils universels : adaptez-les aux objectifs de votre service et vérifiez-les en charge avant le déploiement.

const traitements = [
  { nom: 'valider une commande', dureeMs: 40, elements: 1, critique: true },
  { nom: 'enregistrer une commande', dureeMs: 120, elements: 1, critique: true },
  { nom: 'generer une facture', dureeMs: 1800, elements: 1, critique: false },
  { nom: 'exporter les commandes', dureeMs: 9000, elements: 50000, critique: false }
];

for (const traitement of traitements) {
  const aExaminer = traitement.dureeMs > 500 || traitement.elements > 1000;
  console.log(
    `${traitement.nom}: ${traitement.dureeMs} ms, ` +
    `${traitement.elements} element(s), ` +
    `dans la reponse=${traitement.critique}, ` +
    `a examiner=${aExaminer}`
  );
}

valider une commande: 40 ms, 1 element(s), dans la reponse=true, a examiner=false
enregistrer une commande: 120 ms, 1 element(s), dans la reponse=true, a examiner=false
generer une facture: 1800 ms, 1 element(s), dans la reponse=false, a examiner=true
exporter les commandes: 9000 ms, 50000 element(s), dans la reponse=false, a examiner=true

Dans cet exemple, la validation et l’enregistrement restent dans le chemin critique parce que la réponse dépend de leur résultat. La facture et l’export sont signalés pour examen en raison de leur durée ou de leur volume ; ce classement invite à définir leur mode de traitement et leur comportement en cas d’incident. Dans votre service réel, mesurez aussi les variations de durée : une moyenne seule peut masquer des attentes très longues pour certains clients.

À retenir

• Tracez les étapes que le serveur doit terminer avant de répondre : elles forment le chemin critique.
• Gardez dans la réponse les opérations courtes dont le résultat est immédiatement nécessaire.
• Évaluez chaque traitement selon sa durée, son volume et les conséquences d’un échec.
• Définissez ce qui doit rester disponible et ce qui doit pouvoir être repris après un incident.
• Confirmez vos hypothèses par des mesures représentatives plutôt que par des seuils supposés universels.

À la prochaine leçon, vous séparerez la configuration du service selon l’environnement et préparerez sa validation au démarrage.