Тимур Шемсединов

// при старте делаете просто
global.api = {};
['fs', 'os', 'util', 'http'].map(function(m) {
  api[m] = require(m);
});
...
// теперь в любом файле пишете
api.fs.readFile(...);

Socket.io не нужно ни для чего. Посмотрите этот пример на вебсокетах: https://github.com/HowProgrammingWorks/WebsocketChat

Через колбэки

function getLastTime(callback) {
  var last = default;
  redis.get('redis_key', function (err, result) {
    callback(result);
  });
}
// Usage:
getLastTime(function(last) {
  console.log(last);
});

var config = require('config'); // подгрузка npm модуля с именем config
var config = require('./config'); // подгрузка файла config.js из текущего каталога
var config = require('../config'); // подгрузка файла config.js из каталога на 1 выше
var config = require('../config.js');  // то же, что и предыдущая строка

Ситуацию Вы уловили. Имеет ли смысл использовать чистый Node.js? а не фреймворки типа Express?

Use the Global, Luke!

// In application entry point or framework
global.api = {};
api.fs = require('fs');
api.http = require('http');
require('./db');
require('./application');
global.db = new api.db.createDatabase();

// In DB module: db.js
api.db = {};
api.db.createDatabase = function() {
  console.log('Create DB');
};

// In any place and any applied module
db.select('.....or whatever you want');

Еще хорошо освоить песочницы для экранирования модулей и прикладного кода в разных глобалах: https://github.com/HowProgrammingWorks/InversionOf...

Смотря где на сервере хранятся данные о занятых местах и как происходит бронирование. Например, если таблица мест в базе, и для занятия следующего случайного из ноды нужно сделать два запроса:
1) Выбрать случайное
2) Пометить выбранное занятым
То между этими запросами может втиснуться запрос от другого пользователя и все испортит. А вот если эта операция атомарная, т.е. отправляется в СУБД и 1 и 2 вместе и возвращается номер случайного места, то все будет ок. Но лучше всего в этой ситуации, сразу забрать все места в память в массив, один раз их там перемешать случайным образом. arr.sort(function () { return Math.random() - 0.5; }); и потом брать по запросу один arr.pop(); и если сервер в одном потоке, то это гарантирует, что ни кто не возьмет один и тот же. А вот сохранять в базу можно уже в отложенном режиме. Если поток запросов очень большой, то сложнее, тут уже одним потоком не обойтись, тут нужно делить массив на блоки и держать каждый блок в отдельном процессе или отдельном сервере.

Статику отдают через CDN, а exspress, что торчащий голой жопой, что спрятавшийся за торчащим nginx`ом, годится только для прототипирования.

Читайте: Что можно написать на Node.js?

Попробуйте к командам установки добавить впереди sudo еще, возможно, нехватает прав перетереть поверх ту версию, что уже стоит.

Проще всего этим приложениям обмениваться HTTP запросами на localhost, но при большой интенсивности таких запросов, или при необходимости оптимизировать время отклика - это становится не эффективно. Тогда есть куча других средств IPC, сокеты, мьютексы и семафоры, файловая система, файлы отображаемые в память (или разделяемая память), через базу данных, через шину событий и очередь сообщений MQ системы (ZeroMQ, ActiveMQ, RabbitMQ, Redis, AMQP и т.д.). Но все эти способы не сильно улучшат ситуацию по сравнению с HTTP, потому, что PHP приложение все время завершается и стартует заново, в общем - долго не живет. При каждом запуске оно опять будет устанавливать соединение или с шиной событий или с базой или сокеты открывать к постоянно находящемуся в памяти Node.js приложению, которое живет в памяти долго. Все перечисленные способы хороши для взаимодействия двух долгоживущих приложений, которые могут установить соединение и использовать его долго, и собственную память держать долго, а через соединение просто синхронизировать состояние нескольких процессов. А в случае с PHP, обычных HTTP запросов хватит с головой, высоконагруженную системы Вы все равно не построите на связке PHP+Node.js, а вот времени сэкономите, если сделаете как можно проще.