Alexander Kaloshin

Для хранения недоставленный сообщений целесообразнее использовать redis и сделать это следующим образом:

Если пользователь в данный момент не онлайн, записывать сообщения в редис через rabbtimq (ZeroMQ) специальными воркерами. Тогда удастся размазать нагрузку и не будет пиков.

Так же желательно все сообщения для конкретного пользователя хранить в его "личном" списке, а не списке комнаты, тогда есть возможность (при необходимости) при успешном получении - очищать кеш и redis не будет раздуваться.

Если же необходимо хранить историю сообщений - желательно написать воркер, который раз в n секунд будет забирать данные из кеша и записывать в БД в отдельную коллекцию или таблицу, и так же очищать кеш.

При подключении пользователя просто делать запрос на получение недоставленных сообщений из кеша, если кеш пуст - загрузить из БД из специальной таблицы недоставленных.

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

Успехов :)

Странно что никто не предложил вам посмотреть в сторону yeoman генератора.
На данный момент ребята как раз стараются создать эталон организации приложений на ноде и других языках.

В наших приложениях мы используем примерно следующую структуру:

├── Gruntfile.js
├── app.js
├── config
│   ├── config.js
│   └── env
│       ├── all.js
│       ├── development.js
│       ├── production.js
│       └── staging.js
├── package.json
├── src
│   ├── controllers
│   │   └── controller.js
│   ├── lib - общие самописные библиотеки для всего приложения (например описание ошибок, логи и т.п.)
│   │   ├── error.js
│   │   ├── logger.js
│   │   └── routes.js
│   ├── modules - законченные модули
│       └── module.js
│   └── models - модель данных
│       └── model.js
└── templates
│       └── template.html

Поддерживаю. Сами пишем только на node.
В большинстве современных платёжных систем доступное API, а большое комьюнити node, уже понаписало всевозможных модулей к ним. Так что используйте смело, но проверяйте.

Есть вариант использовать вместо обычного цикла - Array.pop().
Алгоритм следующий:

var a = [1,2,3];

var magic = function () {
  var i = a.pop();

  if(!i) return false;

  // some magic with i
  console.log(i);
  
  magic();
  return true;
}

magic();

Очень грубый пример, но жизнеспособный. Так же можно это обернуть в события и дергать события.

По порядку:
var postId = req.body.id; - body может равняться null - тогда приложение упадёт. Необходима проверка.

if (req.user) - не совсем корректная проверка, так как далее вы делаете запрос по вложенному полю id, которого может и не быть. А если его нет, то и нет смысла нагружать приложение лишним запросом в БД.

if(req.user && req.user.id) - более грамотный вариант.

Далее: всё верно, одним запросом конечно обновить 2 документа в разных коллекциях нельзя. Но я в вашем случае не вижу смысла использовать библиотеку async. Гораздо более идеологически правильным вариантом освоить событийное программирование. И просто вызывать последовательность событий при выполнении алгоритма.

var error = function (err) {
   //
}
event.on('error', error);

// где то там в глубине кода
if(err)  return event.emit('error', err);
event.emit('user save') // в случае отсутсвия ошибок

Могу более подробно прокомментировать если надо :)

Можете попробовать сервис Last.Backend. С помощью конструктора визуально создать необходимую инфраструктуру... Всё подробно описано в User Guide, как раз на примере деплоя node.js приложения. Сайт проекта http://lastbackend.com, User Guide - docs.lastbackend.com/guide.