No node.js, apenas uma solicitação é executada de cada vez (o interpretador Javascript é de encadeamento único) até que você atinja algum tipo de operação assíncrona no código nativo e, em seguida, outra solicitação comece a ser executada enquanto a outra espera por E/S . Se houver algum recurso limitado que todas as solicitações estão procurando, é apenas uma corrida para ver qual solicitação chega longe o suficiente em seu código para obter o recurso. Se você agrupar seu servidor para aumentar a escalabilidade, cada cluster executará um encadeamento Javascript.

Se você fizesse cada solicitação recebida esperar em uma fila até que todas as outras solicitações anteriores fossem completamente concluídas (algo que poderia ser feito), você destruiria seriamente a escalabilidade do seu servidor node.js e, na maioria das vezes, isso seria ficar ocioso esperando que alguma operação de E/S seja feita, então parece improvável que esse seja o design correto.

O esquema usual aqui é apenas permitir que a primeira solicitação que chegue para reivindicar o recurso o tenha (mesmo que vários recursos possam estar sendo executados ao mesmo tempo). Se este é sempre o pedido que chegou primeiro ao seu servidor ou não, não será conhecido, mas será próximo e é improvável que a comunidade de usuários saiba se ele foi desativado por alguns milissegundos apenas devido à variação de velocidade de processamento de duas solicitações.

Você terá que garantir que seu código que acessa recursos compartilhados (como bancos de dados) seja seguro para simultaneidade e não faça suposições problemáticas sobre dados compartilhados.