Ну поэтому совет хотел узнать)

Ищи конкретно для монги, select for update

Или поменяй на атомарный инкремент

И так atomic. Я о том что юзер может быстро кликать на кнопку и пока монго получает и меняет бд в первом запросе, второй получит неправильные данные с бд

Значит не атомарно обновляешь)

Если есть возможность влезть между селектом и апдейтом с новым селектом

Так он не для локов

Ну я локи хотел точнее

Можешь функии монги использовать $inc

Вот тебе атомарный апдейт

Позднее покажу пример

вот пример. можно представить что через rest api идет вызов на insertUser(email). внутри проверяется есть ли юзер с этиим email или нет, через count. если нет добавляется. так вот если оба запроса будет параллельными, то пока первый проверяет и пишет данные в бд и пока еще не дописал, тем временем второй будет проверять , то второй получит count 0 и напишет в базе тоже. будет 2 юзера с таким же email. я понимаю что так не проверяют уникалность в монго, но это чисто пример где надо будет юзать lock.

Уник индекс на email поможет

да не об этом я. конечно же поможет, но представим что юник индекса в монго нет. у меня в коде такие проблеммы с локами, когда прям надо замарозить участки кода, не одна операция. поэтомму я спрашиваю про локи и нест

Тогда отвечу так, нест не решает проблему локов потому что не должен

Тут берешь/пишешь решение для ноды без завязки на нест и работаешь с ним

Но по факту тебе нужна некая очередь обработки команд

Более конкретно на абстрактный вопрос не смогу ответить

спасибо, я смотрю в сторону mutex, думал обертки будет на нест

Глянул сейчас что из мьютехов есть

https://www.npmjs.com/package/async-mutex