d'Ivan

Так же, как бэкенд на любом языке и фронтенд на любом фреймворке - по протоколу http.

package main

import (
    "encoding/json"
    "net/http"
)

func main() {
    http.HandleFunc("/api/data", func(w http.ResponseWriter, r *http.Request) {
        data := struct {
            Message string `json:"message"`
        }{
            Message: "Привет, мир!",
        }

        w.Header().Set("Content-Type", "application/json")
        w.WriteHeader(http.StatusOK)

        if err := json.NewEncoder(w).Encode(data); err != nil {
            http.Error(w, err.Error(), http.StatusInternalServerError)
        }
    })

    http.ListenAndServe(":3001", nil)
}

В целом так же как и на node, python, dotnet)
Делаешь небольшой сервер с endpoint, в этом случае /api/data и делаешь на него запрос с react, localhost:3001/api-data, делать запросы можно через fetch, axios. Ну и описываешь route дальше. таких роутов можно делать много, это вариант http запросов. Еще есть gRCP, ну для начала лучше разобраться с этим)

здесь это описано: https://habr.com/ru/articles/160477/

не используй indexedDB - это неудобно
используй библиотеку localForage https://habr.com/ru/companies/nordavind/articles/2...

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

Из математики обязательно: матрицы, тригонометрия, плани/стереометрия (декартовы координаты). Без этого вообще никак - это основа основ.

Из ЯП стандартно: алгоритмы поиска, сортировки, структуры данных (особенно деревья), ну и навык проектирования и архитектуры больших систем

Знать нужно много чего...
Само собой программирование: C++, C#, Java или другие.
Математика: необходимо знание основ алгебры, геометрии, тригонометрии и математического анализа.
Физика: нужно знать основы, чтобы моделировать физические взаимодействия в игре.
Графика: нужно знать, как создавать 2D и 3D графику, а также как обрабатывать изображения.
Звуковое сопровождение: принципы работы со звуком, чтобы создать качественное звуковое сопровождение для игры.
Геймдизайн: нужно иметь представление о том, как создать интересный и увлекательный геймплей.
Сетевой код: если хотите создать многопользовательскую игру, то необходимо знать, как реализовать сетевой код.
Оптимизация: нужно уметь оптимизировать код, чтобы игра работала быстро и без сбоев на различных устройствах.

Ну и, естественно, уметь пользоваться поисковиком, так как искать придется много разной информации.

1. Если в разрабатываемой системе нет потребности производить нечеткий поиск, получать сверхбыстрый ответ на запрос в реальном времени (не более пары миллисекунд), производить аналитику данных в самых разных разрезах. У вас в потоках данных определены сущности с четкими реквизитами и сущности имеют высокую связность, то в 99% случаях вы даже не повернете голову в сторону нереляционных СУБД, будете использовать реляционные.
2. На самом деле, просто зависит от того, как сложно администрировать СУБД в том масштабе, в которой развилась база данных. Сначала берут первую попавшуюся, или с тем, с чем освоились более-менее, а потом смотрят с течением времени, как сложно нанять нужного специалиста на администрирование, удобно ли масштабировать экземпляры баз данных при возросшей нагрузке, удобно подымать экземпляры из небытия, держать непрерывный аптайм. Вот тут уже выясняется специфика работы предметной области и необходимость переезжать на подходящее окружение.

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

Какую конкретно? Ту, которую лучше знаешь, если не можешь назвать конкретную причину, почему лучше изучить другую и взять другую. Например вот я беру postgres по-умолчанию, но вот у меня проект, который требует минимального жора ресурсов и наиболее простой инфраструктуры - тогда беру sqlite.
Или наоборот - я понимаю, что у меня какие-то специфичные требования по консистентности и доступности, система у меня будет распределённая, а запросы у меня будут исключительно key-value, да и желательно ещё иметь возможность подписки на изменения каких-то ключей - тогда беру etcd.

Очень большая - это какая? Больше 100млн записей? Тогда clickhouse (как я могу понять данные будут писаться и не обновляться). База позволит делать по данным аналитику.
Меньше 10млн - любая классическая бд типа мускуля справится.

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

В принципе, все)

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

Если поисковый запрос начинается с символа %, то индекс толком не используется.
Вам нужен либо fulltext index и соответствующий запрос, либо сторонний поисковый движок типа эластика или мантикоры

Или хотя бы перенести сайт с того утюга, на котором он хостится сейчас, на нормальный сервер. Потому что 10 секунд на перебор трех сотен тысяч строк - это запредельные какие-то цифры.

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

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

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

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

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

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

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

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