lega

Загляните в syslog, возможно это oom-killer убивает могу когда та начинает жрать всю память (если так - то нехватка памяти), так же ещё сделайте swap если ещё нету (а если есть, что показывает?).

Обновлять по id, id искать по куке, куки могут быть как в объекте пользователя так и вне.

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

Я бы сделал простой запрос по индексу (from-to) - получить все занятые на период. И уже на бекенде (из кеша или монги) выдал бы все что не попали в список (т.к. номеров не много).
Это один из самых производительных вариантов. А сложные запросы и запросы с отрицанием (not) часто приводят к полному перебору.

PS: но для учебного проекта не факт что подойдет.

как потом фетчить посты всех этих юзеров

db.post.find({ author_id:{ $in: friend_list }})

На сегоднящний день поддерживают 68.71% браузеров*.
https://caniuse.com/#search=await

Храните общую площадь в документе - проще и работает на порядки бытрее на больших коллекциях.

$push добавляет в массив, а у вас *red* - объект, в объекте дублей ключей не может быть

В минтуте не всегда 60 секунд ;-P

Или же это все нужно делать уже на клиенте ?

Да, сортировка для документов, а не для их содержимого.

Нет

На сервере где функция меняет xp, там и пусть уровень высчитывается и записывается а базу с тем же обновлением, для события - тут же проверяете изменился ли уровень и что-то делаете, например отправка сообщения клиенту.

_id - это поле для уникального индекса, т.е. монга предотвращает появление дублей.
Значит вам нужно записать туда разные значения, сейчас вы пытаетесь записать туда дубль.
Если не трогать это поле, драйвер сам должен подставить туда уникальный ObjectId.

Не бьёт ли это по производительности?

Бьёт

он является так таковым пуш-сервером (отслеживает изменения в БД и отправляет нужные данные подключенному клиенту

Селекты не нужны, код который меняет данные в БД пусть рассылает сообщения через rabbitmq/zmq и т.п.