Ростислав Игнатенко

Paypal и Netflix используют Node.js. У обоих нагрузки очень даже приличные.
В плане масштабируемости думайте об архитектуре. Можно и на perl написать приложение, которое за секунду будет обслуживать миллион клиентов.
Node.js будет прекрасно работать в качестве движка для типичного веб-приложения вроде магазина, чата или CRM. Если у вас очень много компонентов, например тысячи, логичнее приложение разбить на модули и сделать вместо одного приложения несколько, которые можно запускать по-отдельности (здесь уместно упоминание микросервисной архитектуры). Разумеется запросы нужно распределять с помощью балансировщика.
Есть еще такая вот штука https://serverless.com/ - ее можно масштабировать практически до бесконечности. Были бы деньги.
Node.js будет плохо работать в области процессинга данных, например генерация картинок, потоковая обработка видео, нейронные сети и т.д. Здесь лидеры C, C++, Go, Rust, Java.
Можно даже создать гибридное приложение - большую часть выполнить на Node.js, а критичную по производительности на другом языке. Например генерация миллиона прайсов в сутки в старый xls или векторный pdf, упаковка в архив и рассылка - не самая лучшая идея для Node..JS. То же C++ здесь будет вне конкуренции.

Нельзя.

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

Думаете, 10 бесполезных ответов лучше, чем один бесполезный вопрос?

К тому же, тут и без новичков достаточно таких ответов, а с такими правилами тостер вообще в помойку может превратиться

В БД (или быстрый кэш, типа Redis). Причин несколько:

• Ваше приложение может упасть. Игрокам не понравится, если у них вдруг пропадут карты. БД тоже падают, но вероятность этого гораздо меньше (у них больше разработчиков и тестеров).
  
• Массивы в памяти не масштабируются. Положим, пару десятков одновременных партий в памяти держать можно, но когда счет пойдет на тысячи, это будет жрать RAM, плюс тормоза на GC. А БД можно вынести на отдельный сервер и даже на отдельный кластер.
  

Ну, понятно, что в учебном примере пофиг на надежность и масштабируемость, но почему бы не делать сразу правильно?