Nuts

Во-первых, у Nginx очень высокая производительность при очень низкой требовательности к ресурсам сервера. В вашей схеме сотня тысяч одновременных запросов на статику будет обработана в разумный срок и никак не скажется на производительности бэкенда. В схеме заказчика, тормозить начнёт и отдача статики и бэк, не исключено, что сервер вообще перестанет отвечать на запросы.

Во-вторых, Nginx очень надёжный и безопасный. Не в последнюю очередь потому, что в базовой комплектации прост как кирпич. Обеспечение того же уровня устойчивости к взлому для IIS, требует существенно больших умений и трудозатрат админа.

Все запросы нужно направлять на главную страницу.

web.config

<system.webServer>
  <rewrite>
    <rules>
      <rule name="All" patternSyntax="Wildcard" stopProcessing="true" enabled="true">
        <match url="*" />
        <conditions logicalGrouping="MatchAll">
          <add input="{REQUEST_FILENAME}" 
               matchType="IsFile" 
               negate="true" 
               pattern="" 
               ignoreCase="false" 
          />
        </conditions>
        <action type="Rewrite" url="index.html" />
      </rule>
    </rules>
  </rewrite>
</system.webServer>

После внесения изменений, не забудьте перезапустить рабочий процесс (пул).

В кластерном 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://vscale.io/ подойдёт

Мотивирующая серия статей:
1. https://codeseller.ru/post-group/legko-li-ujti-vo-...
2. https://codeseller.ru/post-group/problemy-razvitiy...
3. https://codeseller.ru/post-group/frilanser-i-ip-es... - собственно что вы и спрашиваете "Фрилансер и ИП — есть ли смысл?"

Ankhena W достаточно подробно все описала, но кое-что следует уточнить.

1. Проценты и em это всё-таки разные единицы измерения. Для каких-то свойств они ведут себя одинаково (в частности font-size), для каких-то - по-разному. Например, при задании line-height процент высчитывается от размера шрифта текущего элемента, а em от размера шрифта родителя.

2. То же самое. Зависит от свойства, к которому применяется.

3. Можно использовать (и используют), но не всегда это нужно. Допустим, элемент small должен быть всегда меньше на 25% где бы он не находился. Чем писать правила на все случаи его появления в верстке, проще написать одно правило - font-size: 0.75em;

4. Неточность у автора. body наследует не настройки браузера, а свойства рутового элемента html, который как раз и задается настройками браузера (по умолчанию).

5. Отступы в em удобно задавать при описании типографики, но не блоков. Например, для заголовков, параграфов и т.п. Вообще, если описывать всю типографику относительными единицами, ее легко, буквально в пару правил, адаптировать под разные экраны.

И по всему остальному: истины нет. Неожиданно, да? Тем не менее это похоже на правду. Всё зависит от конкретных обстоятельств. Где-то удобнее использовать одно, где-то другое. И прекрасно, что CSS дает нам такую возможность.

Старое уже видео, но всё понятно
https://youtu.be/w4EHA9xqoNw

localeCompare имеет смысл, если у вас строки могут быть на разных языках — например, выводите список языков как в Википедии, или список названий стран на их официальном языке, или нужно провести поиск с учетом диакритики.
Если же это что-нибудь вроде if (message.type === 'error'), то, конечно, ===.

Ну давайте я покритикую:

возьмем файлик

1) вы не разобрались как объявлять методы у прототипов с новой нотацией `class`:

class Travelsort {
    constructor() {}
    sortTickets(tickets) {}
}

2) вы не умеете пользоваться исключениями.

if (!Array.isArray(cards)) {
    throw new ValueError('Wrong input');
}

3) использование let там где должен использоваться const

4) в принципе использование переменных там где их быть не должно

5) вы зачем-то реализовали свою функцию сортировки, я не увидел в требованиях отсутствия возможности использовать старый добрый Array.prototype.sort

6) Общие замечания по кодинг стайлу. snake_case там где должен быть camelCase, пишите с большой буквы то что должно быть с маленькой и т.д.

7) нарушения принципа единой ответственности. У вас объеткт умеет и сортировать и писать куда-то. Это категорически плохо.

8) Если исправить 7-ой пункт то наш класс превращается просто в функцию.

Далее... берем следующий файлик

1) если вы пишите комментарии к таким маленьким кускам кода - стало быть у вас хромает именование вещей. Все должн быть понятно просто из названий методов/функций/переменных. При работе в команде над серьезными проектами это немаловажно, ибо код чаще читают чем пишут и экономить нужно именно это время.

2) вы зачем-то тут в прототип объекта строки впихиваете функции для парсинга CSS. Таким образом мы нарушаем принцип единой ответственности. Да и в целом расширять без надобности прототипы объектов как-то не ок.

Чуть дальше проскролил - вы пытаетесь расширить прототип строк для того что бы добиться API jquery? ух, батенька.

3) очень много дублирования.

4) очень плохо с protected variations.

Справедливости ради, ваш код входит в категорию ">50% JS кода", так что не расстраивайтесь. Просто для работы в яндексе нужен чуть более высокий уровень и понимание вещей.

«Отзывчивый веб-дизайн» Итан Маркотт
Небольшая книга, в ней с примерами рассказано что и как.