mamont80

Ramdisk не даёт эффекта. Операционка прекрасно справляется с кэшированием файлов. Но на всякий случай проверил. Как и ожидалось эффекта не было.

Думаю вопрос сложнее чем кажется. Не так важно через какой механизм вы будете получать обновления, вебсокет, longpooling или простой опрос. Я бы начал с простого опроса, потом бы переделал.
Юзер может быть за прокси, а прокси не держат вебсокет. Может "мигнуть" интернет, браузер может выгрузить вкладку, комп заснул. Может произойти много всякого и вы не должны полагаться на постоянство связи клиент-сервер.
Важно что клиент должен знать своё текущее состояние и получать список изменений состояния. Обычно состояние имеет номер, при изменении номер увеличивается. Зная номер предыдущего состояния, можно получить список изменений до последнего состояния. Это общая концепция. Возможно у вас могут быть ещё конфликты правок, уже сами прикинте на сколько сложным будет dif. Может быть что список изменений слишком большой и проще перегрузить всё состояние, чем принять dif.

база просто не будет держать запросы

Это ж MongoDB, в которой из коробки шардинг и реплики. Будет нагрузка - будете думать.

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

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

В случае репликации, как определять, что данные на слейвах

Опять таки это решает сама MongoDB.

Подскажите, как более грамотно здесь поступить?

Грамотно - это запустить проект и решать проблемы по мере их поступления. Если вы не запускаете СуперУбийственныйПроект, то нагрузка будет расти очень постепенно. Будет время подкручивать-оптимизировать.