lega

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

Теги складываете в массив внутри документа и его индексируете - будете быстро находить документы по тегу.

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

Плохое решение, так сессию не заиндексировать - а значит монга будет делать full scan коллекции, что приведет к тормозам при росте коллекции.
Как компромис - можете продублировать сессю в массив и сделать на него индекс.

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

Смотрите логи, может быть нехватка оперативы или места на диске

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

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

1) Если кол-во искомых слов не большое, то можно сделать массив в документе и там хранить.
2) Использовать текстовый индекс
3) Если коллекция небольшая то можно $regex, но на больших коллекциях будет тормозить т.к. это полный перебор всех документов.

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

оберните монго-драйвер во врапер который и будет разруливать что куда

Как правильно проверять чтобы одинаковых слагов не было?

Сделайте уникальный индекс на это поле и дублей не будет.

Не храните дубли да и все.

Я бы подумал о таком варианте (posts):

{
  votes: 15,
  vote: {
    user1: 1,
    user2: -1
  }
}

Одним запросом и пересчет и защита от повторного голосования, и выборка одним запросом.

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

По сути пол field это чекалка отправки уведомлений, т.е. 0 не отправлять ответ пользователю, 1 отправлять.

Если вам нужно включать/отключать значение по всем комментам в пределах пользователя, то зачем это значение хранить в каждом коменте.
Для обновления по ключу используйте словарь вместо массива.
Пример:

{
  comments: [],
  flags: {
    user1: true,
    user2: false
  }
}

С такой структурой, вы можете включить/выключить флаг по пользователю по всем комментам (всему документу), а если нужна возможность переключать конкрентные комменты, то можно рядом хранить в разрезе пользователь-коммент ( flagsByComments:{ user2: {comment1: true, comment2: false} }).

Про сложность обновления, если у вас на 1000 чтений 1 запись, то не страшно, что обновление сложное, главное чтобы чтения были быстрые.

Т.е. при 1000 комментариев надо 1000 раз проверить, и возможно из них 100 раз выполнить запрос на обновление.

С локом достаточно будет одного обновления (ну и +1 обновление для лока, хотя не обязательно, зависит от типа лока)

список топиков отсортированных по дате последнего сообщения в них для него

Для этого в топике нужно хранить дату последнего сообщения.

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

Даже если бы вы использовали SQL, такая колонка была бы желательна, и необходима для худшего случая.

Первый вариант ещё делится на 2: хранение свойств в документе пользователя, и хранить свойства в документе друга.

Если все (или много) свойств нужно получать каждый раз (часто), то 1-й вариант лучше, т.к. будет давать все данные за минимум запросов, и это может работать в сотни/тысячи раз быстрее чем возня с миллионной коллекцией.
Так же тут будет экономия на индексах, + лучшее сжатие данных.

Если вам нужно за раз только одно/два свойства, то скорее 2-й будет лучше.

Также нужно учесть лимит в 16мб на документ.