VoidVolker

В данном случае проще всего будет просто связать оба инстанса друг с другом и использовать второй инстас как резервный. Например через банальную проверку друг друга по сети запросом каким-нибудь. Один инстанс работает, а другой проверяет, что первый инстанс работает верно. Если первый инстанс не отвечает, висит, сломался и т.п. - в работу включается второй и где-нибудь ставит флаг/файл/что угодно и как, что теперь он основной, а первый - резервный будет, когда заработает и отправляет сообщение ответственному.

Чуть более сложный вариант: использовать, например, редис для хранения состояния процесса работы и через него синхронизировать инстансы. Например: первый сервис определил для себя задачу и сообщает об этом второму, что он взял такую-то задачу или такие-то файлы. Соответственно второй сервис эти файлы не трогает. Или, оба инстанса смотрят в каталог, как только что-то обнаруживают - помещают в очередь задач. А при появлении задачи в очереди - оба сервер генерируют случайно число и так выбирают кто из них возьмет следующую задачу из очереди. Т.о. можно, этих инстансов наплодить сколько угодно.

Более правильный вариант: разделить функционально вашу задачу на несколько более простых. А именно: вместо проверки каталога, запустить на том сервере, где находится данный каталог с файлами сервис наблюдения ФС, который использует системные уведомления об изменениях файловой системы. И при наступлении нужных событий - отправляет запрос в очередь на обработку, например в тот же редис, а оттуда запрос забирает один из инстансов и обрабатывает его.

Никак. Выбор инструмента - это задача тимлида и/или техлида. Т.е. ведущего/главного разработчика, отвечающего за принятие ключевых технических решений. Ваша задача, как заказчика, четко оформить требования, ограничения и сформировать начальное ТЗ и описание, что вам требуется от проекта, прототипы интерфейса, например. Без вникания в технические детали. Т.е., "хочу чтобы были фичи такие-то и работил они так-то, ограничения такие-то, требования такие-то". Далее уже задача найти разработчика/команду с большим или достаточным для данного проекта опытом. Далее из начального ТЗ формируется полноценное техническое задание: описывается весь требуемый функционал, рисуется дизайн, прописываются требования, ограничения и прочие хотелки. И на основе ТЗ, тим/тех лид уже подбирает/подбирают наиболее оптимальные и конкретные инструменты и решения, основываясь на собственном опыте и знаниях для конкретно этой задачи. Например, если человек хорошо знает несколько разных инструментов и есть достаточный опыт их использования - он может реализовать проект используя любой из них как одинаково хорошо, так и одинаково плохо. У разных ЯП и фреймворков свои плюсы и минусы. Далее из ТЗ формируется более детальное ЧТЗ и происходит разработка проекта.

Вот вы говорите:

Нужно будет выполнять много запросов к БД

Важная быстрая скорость работы нашего сайта

Много/быстро это сколько? 100 запросов в час? 1000 в минуту? 1М в секунду? Загрузка страницы за 30/10/1с или даже 100мс? А к какой именно БД? Какая характеристика самих данных и какого типа запросы? На какое количество соединений? В каком регионе? Есть ли там тяжелые или еще какие-то вычисления? Медиа файлы - картинки, видео? Тут очень много нюансов. В идеале следует определиться с конкретными значениями/параметрами и их описать в ТЗ. Ну или определить примерное, а фактическое значение определить на стадии прототипа/MVP и/или провести какое-то исследование/тестирование. Можно потратить десяток лямов на написание крутого кода на го/расте/С++/ассемблере в течении года и все будет летать на простейшем сервере. А можно купить свой сервер за лям (ну, условно, конечно), нанять питонщика или PHP-ника за 300к и он за пару-тройку недель добьется такого же результата. Большинство веб-задач сегодня достаточно просто или с минимальными усилиями решаются абсолютным большинством решений для веба. Да, у всех решений есть свои плюсы и минусы.

Безопасность от всяческих XSS и SQL атак.

Вот с этим проще: использовать популярные OpenSource решения, регулярно проводить тесты, нанять отдельно опытного разработчика, красноглазика и пентестера - и тратить на них деньги, пока деньги не кончатся или не будет достигнут необходимый уровень безопасности. Безопасность противоположна удобству, защита отстает на шаг от атак. Риск есть всегда и надо просто быть готовым к последствиям и иметь запасной плат хотя бы в общих чертах.

А так - уже правильно посоветовали сразу брать дот-нет, т.к. у вас требование к использованию конкретной библиотеки для дот-нета.

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

как можно реализовать сами комнаты?

Структурой.

Можно ли представить комнаты потоками?

Можно, но не нужно. Это несколько разные концепции. Комната - это набор данных. Поток - это процесс обработки данных.

Тогда получится ли корректно работать с двумя игроками в одном потоке?

Вполне. Обратите внимание на существующие онлайн игры - тысячи и миллионы игроков.

Или каждый игрок обязательно должен быть самостоятельным потоком, и информацию о комнатах нужно хранить отдельно?

Опять путаете процесс и данные. Игрок - это тоже данные.

Правильно заданный вопрос уже содержит половину ответа.

достаточно ли его в качестве архитектуры?

Достаточно ли хорошо решает поставленные перед ней, а так же бизнес-задачи данная архитектура?

Что ещё следует учесть при разработке чтобы архитектура была действительно true?

Удовлетворяет ли данная архитектура на 100% бизнес-требованиям к ней и на сколько качественно? И если нет, то почему именно?

Что посоветуете изучить, почитать, (подсмотреть :) )по этой теме ?

Разработка ПО и его архитектуры, жизненные циклы ПО.