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