rPman

В конечном счете все решает стоимость решений

Выделенный сервер (dedicated server upd или bare metal) - это буквально физический сервер, мощности которого принадлежат тебе и твоим программам
Виртуальный сервер (virtual private server) - это когда физический сервер делят на части и продают по отдельности, что сильно дешевле, и удобнее хостеру (он может перекидывать виртуальные машины между физическими, оптимизируя нагрузку), мало того он может оверселить, продавая и обещая больше мощности чем доступно в среднем, надеясь что пиковую нагрузку сервис клиента будет давать редко а остальное время она будет низкой (так обычно и бывает), такие машины обычно самые дешевые (когда видишь предолжения ниже ~30$ это оно самое)

Кстати нормальная практика даже для dedicated server жесткие диски заменять на NAS например iscsi, а реальный диск предлагать как опцию. Сетевые накопители обычно медленней но сильно дешевле для хостера, так как их так же можно делить, снапшотить (например за их счет делать дешевый бакап) и оверселить (а главное централизованное обслуживание, так как диски чаще всего выходят из строя).

Благодаря возможностям приложений виртуальных серверов, у пользователей есть очень гибкие возможности по изменению конфигураций машин (cloud), практически 'на лету', в отличии от выделенных серверов, где установка дополнительной памяти или жесткого диска означает буквально физический доступ к серверу. А некоторые хостеры предоставляют еще и средства по автоматизации развертывания виртуальных машины, т.е. сервис сам автоматически от нагрузки может докупать нужные мощности и ресурсы по требованию, и освобождать их когда они не нужны, оптимизируя траты.

Но нужно понимать что фишки гибкой конфигурации даются не бесплатно и если у тебя постоянная нагрузка, VPS оказываются дороже dedicated server. Правильный подход кроется в комбинировании.

И еще одна услуга у хостеров - предоставление не сервера а услуги - доступа к програмному обеспечению по какому то внутреннему алгоритму тарификации (Software As A Service). Например можно приобрести услугу http сервера (или к примеру хостинг nodejs бакэнда, отдельно базы данных, сервиса бакапов и т.п., такие точно есть), без покупки самой машины, с тарификацией по запросам, трафику или по внутренним cpu тикам, при этом пользователю не важно, сколько там в реальности задействовано серверов, хостер будет обеспечивать заказанный трафик с обещанной скоростью, только плати. Такие крупные провайдеры как гугл или амазон могут встраивать в свои прайсы на такие сервисы ловушки, не изучив и не подготовившись как следует к которым можно попасть на значительное повышение стоимости, к тому же часто такой доступ еще и привязывает клиента к конкретному провайдеру, так сильно что когда придет известность и нагрузка, может не получиться легко сменить хостера на более оптимальный.

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

после 10.5 версии были добавлены worker_threads гре разработчик может создавать настоящие треды, но для доступа к данным из соседних потоков нужно использовать соответствующие типы данных, например слать сообщения или создавать SharedArrayBuffer...

p.s. так как адекватных структур данных для многопоточного доступа в nodejs не завезли, то вся работа покроется кучей лишнего кода для реализации недостающего функционала, поэтому если это так критично, лучше реализовывать важные места на более адекватных языках программирования

скрипт придется компилировать, либо заранее либо таскать с собой golang (гуглить: portable golang) если же нужно еще и оффлайн, то заранее подгрузи нужные зависимости
запуск приложения из electron:

var child = require('child_process').execFile;
var executablePath = "myapp.exe";
var parameters = ["--my_param"];

child(executablePath, parameters, function(err, data) {
     console.log(err)
     console.log(data.toString());
});

Логирование и синхронизация точного времени на сервере и клиенте.

Точный момент (миллисекунды), когда запрос 'пришел' на сервер зависит от точки, в которой происходит замер, например если замерять средствами nginx (запущенный на сервере) и к примеру момент, когда запустится cgi скрипт (первой строчкой которого поставить запись времени в лог) - будут отличаться на десяток миллисекунд.

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

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

Так же номер можно паковать в другую систему счисления с основанием больше 10 (добавив большие маленькие буквы, как это делают в base64)

В этом случае имя файла не превысит 4-5 символов плюс расширение (от него тоже можно избавиться, если сборка будет подготавливать конфиг для вебсервера, чтобы статика возвращала правильные заголовки content-type, но это кстати часто и не требуется)

Что значит

Не лезть же каждый раз в БД, чтобы выдать пользователю информацию о других пользователях в его комнате

?

У тебя websocket, что подразумевает что на клиент передается оперативная информация (изменения) а не полное состояние по таймеру, значит клиент самостоятельно хранит в себе необходимую информацию в коде на javascript в массивах или localstorage, если это так критично