Aleksei Podgaev

Если хранить координаты в отсортированном массиве (X и Y отдельно), то проверять нужно будет только ближайших соседей, до тех пор, пока разница координат не превысит вашего минимального расстояния. Такая оптимизация тем эффективнее, чем меньше данное расстояние относительно размеров поля. Плюс кэшировать результаты сравнений, чтобы не проверять уже проверенные пары. Далее можно убивать кэш не каждый кадр, можно в четных кадрах искать вверх по массиву, а в нечетных - вниз и т.п. Но это уже по факту, если потребуется.

В голове полная каша. Примерно 70% указанных выше пунктов неточны или совсем не верны. Стоит взять любой фреймворк(например angular 1.x, как самый простой и быстрый для изучения) и сделать небольшой spa(можно прям из туториала angular-phonegap). Затем к этому туториалу добавьте бэкэнд в виде экспресса. Большая часть вопросов отпадет сама собой. Что касается изучения уже актуальных фреймворков, несмотря на огромную разницу в реализации общие подходы у ng2/react похожи (components, unidirectional data flow, ...) если понимать сами подходы - изучение основ конкретной реализации не должны занять больше недели. Намного больше времени уходит на изучение экосистемы(flow/typescript/webpack и т.д.)

Лучшее объяснение Redux что я видел.
getinstance.info/articles/react/learning-react-redux

Не совсем по теме..

Супер "полноценных" нет, но где-то тут же на тостере уже всплывала подобная тема. Из давнего (уже) помню soundcloud клиент - статья, github.

Выложить в open-source рабочее бизнес-приложение - практически невозможно.
Выложить какую-то его часть, которая сделана хорошо - уже реальнее, по такому типу можно смотреть на хорошие библиотеки (типа react-virtualized). Но опять же, там "архитектуры" по вашему вопросу нет.
Выложить в общий доступ хороший "учебный" проект - самое реальное. Поэтому может найдется где хорошее платное учебное приложение? А может и бесплатное...

p.s. все же упирается в деньги/время. Если даже бизнес скажет - "выкладывай куда хочешь", то выложите ли вы свою поделку? Вряд ли, так как написано оно было в стиле "пожалуйста, выкати фичу побыстрее, если потом будет время - порефакторишь". Поэтому просто предлагаю писать по мере своих возможностей, а учиться продолжать там же где и раньше, так как полноценное крепкое приложение в опен-сорсе, это почти миф.

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

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

вот метод из сервиса. key под каждый url свой. есть еще способ как в репо angular-universal. там мудренее но зато можно не повторять запросы которые делал сервер node

getUsersActivity(forceRefresh?:boolean) {
return this.getWithCache (
'user-activity',
'usersActivity$', forceRefresh)
};

getWithCache(url, key, forceRefresh?:boolean):any {
     
       if (!this[key]) {
            this[key] = new ReplaySubject(1)
        }

        // If the Subject was NOT subscribed before OR if forceRefresh is requested
        if (!this[key].observers.length || forceRefresh) {
            this.get(url).subscribe(
                (data) => this[key].next(data),
                (error) => {
                    this[key].error(error);
                    // Recreate the Observable as after Error we cannot emit data anymore
                    this[key] = new ReplaySubject(1);
                }
            );
        }

        return this[key];
    }

function(req, res, next) {
  res.render('index', { title: 'Express' });
}

выносишь это в контроллер
./controllers/controllerName.js:

module.exports.routeName = function(req, res, next) {
  res.render('index', { title: 'Express' });
};

В апп подключаешь:

const controllerName = require('./controllers/controllerName.js');
router.get('/', controllerName.routeName);