In node.js, viene effettivamente eseguita solo una richiesta alla volta (l'interprete Javascript è a thread singolo) fino a quando non si esegue una sorta di operazione asincrona nel codice nativo e quindi un'altra richiesta inizia a funzionare mentre l'altra è in attesa di I/O . Se c'è una risorsa limitata che tutte le richieste cercano, è solo una corsa per vedere quale richiesta arriva abbastanza lontano attraverso il tuo codice per ottenere la risorsa. Se si raggruppa il server per una maggiore scalabilità, ogni cluster esegue un thread Javascript.
Se facessi aspettare ogni richiesta in entrata in una coda fino a quando tutte le altre richieste che sono arrivate prima che fossero completate (qualcosa che potrebbe essere fatto), allora rovineresti seriamente la scalabilità del tuo server node.js e la maggior parte delle volte lo farebbe essere inattivo in attesa che vengano eseguite alcune operazioni di I/O, quindi sembra improbabile che questo sia il design corretto.
Il solito schema qui è lasciare che la prima richiesta che arriva per rivendicare la risorsa ce l'abbia (anche se più risorse potrebbero essere in esecuzione contemporaneamente). Non si saprà se questa è sempre la richiesta che è arrivata per prima sul tuo server o meno, ma sarà vicina ed è improbabile che la comunità di utenti sappia se è stata spenta di qualche millisecondo solo a causa della varianza in velocità di elaborazione di due richieste.
Dovrai assicurarti che il tuo codice che accede alle risorse condivise (come i database) sia sicuro per la concorrenza e non faccia ipotesi problematiche sui dati condivisi.
