Dans node.js, une seule requête s'exécute réellement à la fois (l'interpréteur Javascript est monothread) jusqu'à ce que vous atteigniez une sorte d'opération asynchrone dans le code natif, puis une autre requête commence à s'exécuter pendant que l'autre attend les E/S . S'il y a une ressource limitée que toutes les requêtes recherchent, c'est juste une course pour voir quelle requête va assez loin dans votre code pour obtenir la ressource. Si vous regroupez votre serveur pour plus d'évolutivité, chaque cluster exécute un thread Javascript.
Si vous faisiez attendre chaque demande entrante dans une file d'attente jusqu'à ce que toutes les autres demandes qui la précèdent soient complètement terminées (quelque chose qui pourrait être fait), alors vous détruiriez sérieusement l'évolutivité de votre serveur node.js et la plupart du temps ce serait rester inactif en attendant qu'une opération d'E/S soit effectuée, il semble donc peu probable que ce soit la bonne conception.
Le schéma habituel ici consiste à laisser la première requête qui parvient à réclamer la ressource l'avoir (même si plusieurs ressources peuvent s'exécuter en même temps). On ne saura pas si c'est toujours la requête qui est arrivée en premier sur votre serveur ou non, mais elle sera proche et il est peu probable que la communauté des utilisateurs sache si elle s'est décalée de quelques millisecondes simplement en raison de la variance dans vitesse de traitement de deux requêtes.
Vous devrez vous assurer que votre code qui accède aux ressources partagées (comme les bases de données) est sûr pour la concurrence et ne fait aucune hypothèse gênante sur les données partagées.
