Влад Developer: Абсолютно верно, а еще и сама напишет тесты :) А если серьезно, определяйте в своем приложении реурсозатратные части и пытайтесь их оптимизировать и кешировать. Недавно столкнулся с тем, что те же модули для ноды не все одинаковы полезны, например распространенный mysql работает значительно медленнее чем менее распространенный mysql-libmysqlclient. В любом случае разговор о кешировании должен идти в рамках конкретного проекта.
по-поводу чтения сообщений, пользователь заходил в сперва в список диалогов, соответственно при их выборке у меня имелись id и затем при переходе в диалог, серверу передавался его id и происходила выборка сообщений. Сообщение было одно для всех участников (одна запись в БД), только с массивом тех кто еще не прочитал и тех кто его уже удалил (позволило не плодить записи одного и того же), саму же запись производил при публикации сообщения в канал (Redis pub/sub)
Честно сейчас не вспомню все подробности, в общих словах, у меня было две коллекции dialogs и messages, в первой я хранил id диалога, массив пользователей которым он был доступен(в одном диалоге могли общаться более 2х человек, аналог скайпа - чатов или вк), название диалога(тема, т.е. участники могли называть свой диалог, например "Рабочие вопросы"), и соответственно сами сообщения, где был id диалога которому они принадлежат, массивы id юзеров которые прочитали и удалили это сообщение и прикрепленный контент ввиде массива ссылок на графическую и медиа информацию в сети. Упрощенно и словами это было примерно так. Честно сказать у меня текла монга, возможно был нестабильный релиз, если бы не фича с многопользовательскими диалогами, выбрал бы мускул (если бы не хранение массивов и выборка по значениям в нем)