Philipp

Paypal и Netflix используют Node.js. У обоих нагрузки очень даже приличные.
В плане масштабируемости думайте об архитектуре. Можно и на perl написать приложение, которое за секунду будет обслуживать миллион клиентов.
Node.js будет прекрасно работать в качестве движка для типичного веб-приложения вроде магазина, чата или CRM. Если у вас очень много компонентов, например тысячи, логичнее приложение разбить на модули и сделать вместо одного приложения несколько, которые можно запускать по-отдельности (здесь уместно упоминание микросервисной архитектуры). Разумеется запросы нужно распределять с помощью балансировщика.
Есть еще такая вот штука https://serverless.com/ - ее можно масштабировать практически до бесконечности. Были бы деньги.
Node.js будет плохо работать в области процессинга данных, например генерация картинок, потоковая обработка видео, нейронные сети и т.д. Здесь лидеры C, C++, Go, Rust, Java.
Можно даже создать гибридное приложение - большую часть выполнить на Node.js, а критичную по производительности на другом языке. Например генерация миллиона прайсов в сутки в старый xls или векторный pdf, упаковка в архив и рассылка - не самая лучшая идея для Node..JS. То же C++ здесь будет вне конкуренции.

https://www.npmjs.com/package/enchant для Enchant вы можете поставить русские словари.
https://docs.mongodb.com/manual/text-search/ Можно все собрать в одну строку и использовать текстовый индекс, он не так уж и плох.

Если вы хотите сделать действительно хороший поиск смотрите в сторону elasticsearch, solr, sphinx.

Существует модуль позволяющий работать с разделяемой памятью https://github.com/PaquitoSoft/memored

Дело в том, что сейчас многие компании переписывают критичные по производительности части на Go и, в основном старые системы написаны на Node.js.
Плюс выполнить прототипирование новых продуктов проще на Node, а потом можно перейти и на Go.

https://youtu.be/Do_Hsb_Hs3c?t=689

Ваша проблема в том, что приложение изначально ненадежно. Первое, что в таком случае нужно сделать, это запускать несколько копий приложения, если такое позволяет архитектура.
Поскольку у вас будет несколько запущенных копий приложения, вам потребуется балансировщик, чтобы управлять трафиком. Самый простой и дешевый - это nginx.
Например тупо запустить 2 копии приложения на одной машине, но на разных портах, например 8001 и 8002. А при настройке nginx указать два апстрима, первый с портом 8001, а второй 8002. И настроить отвал по таймауту (fail_timeout). Таймаут зависит от того, насколько быстро работает ваше приложение. У меня он 1 секунда, у вас может быть другое значение.

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

Обычно нода падает из-за катяхов в коде, жора памяти или отвала какой-нибудь фигни. Для того, чтобы за всем этим следить, следует поставить хоть какой-нибудь мониторинг ошибок. Например бесплатный sentry.

ЗЫ для любителей микросервисов: микросервисы не делают вашу архитектуру более устойчивой. Они делают ее более гибкой за счет замены одной реализации микросервиса другой. Например, у вас есть датацентр А, в котором вы храните файлы, которые сохраняются через микросервис. Внезапно там кишильбе-мишельбе-молния ударила, сервира уронила, файлы потеряло. Мат-перемат. Запиливается на коленке микросервис для датацентра Б, приложение перенастраивается. Полетели. Потом раскапывается из хлама бэкап, пишется скрипт, заливается в новый датацентр. Микросервисы хороши пока они микро. Микро понятие своеобразное, для меня оно означает - могу запилить за день в одиночку. Примеры: хранилка файлов, постановка задач в очередь, укорачивалка ссылок, счетчик переходов и т.п.

Опиум для народа

Первое, это то, что вам нужно разобраться, как именно работают push-уведомления.
Второе, ненужно порождать лишние компоненты.
Для PHP тоже имеются решения https://packagist.org/packages/minishlink/web-push

Для начала вам потребуется понять, что подписки браузеров нужно хранить в отдельной таблице или коллекции в зависимости от вашего основного хранилища.
Для личных сообщений необходимо будет реализовать опциональную, но включенную по умолчанию связь. Следует помнить о том, что один и тот же пользователь может заходить с разных устройств. Например с десктопа, ноута и таблетки. У одного пользователя может быть несколько подписок.
Вам потребуется сервер очередей, например RabbitMQ. У вас будет 2 вида задач - публичные и частные.
Публичная задача - это широковещательная задача, цель которой охватить всех пользователей.
Например, когда публикуется новый материал на сайте и сайт готов принять всех желающий.
Для него потребуется простая очередь. Задача воркера будет заключаться в том, чтобы найти всех подписчиков, создать задание для каждого из них и поместить это задание во вторую очередь со множеством воркеров, которые будут непосредственно отправлять пуши.
Первое задание будет содержать id - материала.
Второе будет содержать id материала и id подписки.
Данный подход позволит очереди работать очень быстро. Плюс выборка из базы по id практически мгновенна вне зависимости от движка + отлично кэшируется на уровне самой базы. Доставать из базы нужно только необходимый минимум полей.
Рассылка личных сообщений может быть сделана на основе второй очереди, дополнив задание несколькими полями. Т.е. воркерам будет все равно что они доставляют.
Записывать задание со всеми полями для глобальных публикаций не очень хорошая идея, т.к. это будет занимать много памяти и вызывать тормоза. Плюс такое решение не очень хорошо масштабируется.

Воркеры можно сделать и на Node.js, а можно на PHP. У RabbitMQ есть все необходимое для этого. Можно поискать и другие очереди, однако RabbitMQ достаточно популярное и проверенное решение.

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

const messageProcessor = require('path/to/message/processor');
// ваш код идет здесь ...
// далее навешиваем наш обработчик на шину сообщений
messageBus.on('end', messageProcessor);

Так же вы можете автоматическую регистрацию внутри обработчика.

// в вашем основном файле
messageProcessor.register(messageBus);

Внутри процессора сообщений

function messageProcessor() {
 // ...
}

module.exports.register = function(messageBus) {
   messageBus.on('end', messageProcessor);
};

В кластерном Node.js вместо разделяемой памяти используется подход разделяемого хранилища данных.
Обычно эту роль выполняет Redis-кластер поскольку в нем есть механизмы уведомлений (подписок) и возможность асинхронного оповещения узлов кластера.
Такие вещи, как сессии и данные специфичные для клиента (кэши пользователя) хранятся вне Node.Js процесса, например в том же Redis. Это увеличивает инфраструктурные издержки, но позволяет производить бесшовные рестарты и пережить внезапные остановки машин в кластере.

Стандартной практикой является применение балансировщика, например того же nginx, включенного как reverse-proxy. Если вам не очень хочется разбираться с сессиями, используйте ip_hash, это снимет головную боль.

По поводу конкретных вопросов.

традиционные подходы при разработке ПО для кластера Node.js

Традиционный кластер представляет собой множество машин, на который запущено множество процессов через https://nodejs.org/api/cluster.html
Разумеется вместо разделямой памяти вы получаете разделямый сервис. Например с кэшем работаете как с базой и т.д. Почитайте о том, как работает горизонтальное масштабирование.

Что я должен учитывать разрабатывая бекэнд-приложение для кластера Node.js?

Учитывайте факт того, что это новая для вас область знаний. Вдобавок очень популярная и очень перегретая мнениями. Рассматривайте Node.js как некий клей между сервисами и другими решениями. Например ресайз картинок лучше делать на C++, поэтому расходы на создание процесса ресайзинга меньше расходов на ресайз реализованный на Node.js.

Как новый секретный код должен попасть ко всем остальным процессам?

Обычно такие проблемы решаются через провайдер конфигурации, например сервер конфигураций. Любая попытка изменить конфигурацию вызывает изменения во всем кластере. В модуле Cluster это реализуется через механизм уведомлений. В большом кластере такие вещи реализуются через подписки в Redis.

100 позиций этот процесс отдал пользователю в качестве первой страницы ответа, остальные позиции он закешировал

Смотрите про балансировщик и ip_hash. Но в целом подход довольно плохой. Запрашивайте только нужные 100 товаров. Если вытаскивание данных из базы является проблемой, меняйте базу или ее структуру. Масштабируйте хранилище. В крайнем случае используйте разделяемый кэш (Redis, memcached).

Кроме того, являются ли мои примеры корректными, практикуется ли описанное кеширование данных в бекэнд-приложениях на Node.js?

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

Если вы хотите изолировать доставку для отдельных пользователей, вам необходимо использовать комнаты или использовать передачу непосредственно указанному сокету.

https://socket.io/docs/rooms-and-namespaces/#

lollyrock.com/articles/nodejs-encryption

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

Рекомендуется также изменить размер количества одновременных соединений (max-connections) в настройках MySQL.