Alendorff

Я работаю с MongoDB на протяжении уже 4х лет. Имеется ряд проектов, созданных как с использованием этой БД, так и использованием классических RDBMS.
MongoDB это не MySQL и не PostgreSQL. Большинство людей пытается сравнить оба типа баз данных, но это абсолютно глупо и неприемлемо. Это все равно что сравнивать врачей и инженеров.
MongoDB подойдет там, где нужна гибкость структуры и большие объемы данных. Например хранение истории болезни пациентов в масштабе страны. Каждая карточка может быть разного типа со множеством полей. И их могут быть триллионы. Для классических реляционных БД это выливается в весьма нетривиальную задачу горизонтального масштабирования, которая в MySQL решается через перенастройку сервера, а в PostgreSQL через специальную промежуточную таблицу. Горизонтальный рост и ввод новых узлов кластера сопряжен с большими трудностями и плохо автоматизируется для реляционных БД.
Еще классические БД очень плохо работают со смешанной нагрузкой, когда у вас запись/чтение примерно 1:1 и данных очень много. Это вызывает непрерывное перестроение индексов и их использование больше мешает. Это тот тип нагрузки, при которой InnoDB частенько повреждается без возможности восстановления или что вызывает значительный простой на реорганизацию структур данных.
Также существует очень много задач, для которых использование MongoDB исключительно неприемлемо. Если вам необходимо работать с нормализованными данными - используйте реляционные БД. Если нужна мощная аналитика - колоночные. Разумеется, каждая из этих опций имеет свою цену.
На рынке нет универсального решения. Каждое заточено под свои задачи.

В кластерном 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?

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

Чувак, тут нужен системный подход.

Самое простое, необходимое, но не достаточное
Для начала потребуется поднять боевой дух. Здесь нужна ударная доза гормонов счастья: серотонина и дофамина. Фактически, по теме серотонина уже успел высказаться Станислав Макаров: физическая нагрузка, сон, отдых. Но все равно, всегда есть что добавить.

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

Основное, скажем так, мясо мотивации
Разовый прилив гормонов счастья способен вернуть к жизни загибающуюся разочарованную душу, но далеко на этом топливе не уедешь. Эти гормоны, вообще-то, должны вырабатываться сами собой, без привлечения к себе нашего внимания. Но у многих людей механизм выработки даёт сбой, как правило, причины этого имеют психологический характер. Мысли, что ничего не получится, что тлен и мрак, что ночь темна и полна ужасов, - эти мысли повисают мертвым грузом на наших ногах и чертовски отравляют жизнь. Но, к счастью, есть ноги свободные от этих гирь - это ноги людей, которые верят в себя, которых в детстве поддерживали родители. Таким людям легко идётся по жизни, у них всё получается, потому что они не боятся, не откладывают, а делают. Кому не так повезло, и кто с гирями, им придется избавляться от неверия и низкой самооценки уже в пути. Нужно через силу заставлять себя поверить в успех, словом взять на себя ту работу, которую в жизни уверенных людей проделали их родители. Внушать, прямо вдалбливать, что у меня получится, я преодолею это, ну и всё в таком духе. И, повторюсь, поскорее переходить от теории к практике. Будет страшно, но это окупится.

И неправы снобы, говорящие: "Не нужно себя мотивировать. Оставайтесь в жопе". Сколько достойных людей оказалось в жопе в какой-то момент, и погибло, не сумев справиться с судьбой? Есенин. Высоцкий. Кафка, вот уж кто был главный кандидат, чтобы остаться в жопе: был издан после смерти, вопреки завещанию, и оказалось - гений, да каких поискать. Или Гоголь: я бы, вот честное слово, легко променял бы Артемия Лебедева вместе с его великой студией и Татьяной Никитичной на второй том "Мёртвых душ". В общем, много их было, кто в жопе и не вернулся. И никому от этого лучше не стало.