Saboteur

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

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

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

Те, кто работает именно как DBA, это не курсы.
Там где DBA это действительно отдельная позиция, а не сисадмин, который бэкапы делает, там DBA это разработчик баз данных, раньше был в основном Oracle (SQL/PL), где логику бизнес приложений переносили в процедуры оракл базы, и считалось что Оракл такие расчеты будет выполнять лучше и быстрее, так как лучше знает как работать с собственными данными.
Сейчас процедуры уже есть и в постгрес и в облачных базах.
Обычно DBA-шник лучше понимает как должно работать приложение чем фронтендер или даже бэкендер - именно с точки зрения бизнес-флоу, точнее бизнес-данных флоу.

И также есть разделение на высоконагруженные проекты.

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

Как это связано с бэкенд разработкой? Ну не знаю...
Просто научитесь хорошо в SQL и nosql, а там решайте куда выхотите специализироваться.

Микросервисы пишут не для того, чтобы просто переделать API.

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

А уже исходя из этой точки зрения:

1. Если у каждого сервиса есть свой api, зачем API Gateway (точка входа), можно же на nginx сделать обращение по location на нужный api?

А если нужно много экземпляров, будете одним nginx-ом раскидывать по 10 локейшенам? Микросервисы в современном мире предполагается запускать в докере на собственном легковесном веб-сервере (типа Jetty), поднимать нужное количество экземпляров и балансировать чем-нибудь на входе, но не по локейшенам.

2. Стоит ли использовать RabbitMQ для общения между сервисами? Правильно ли понимаю, что точка входа на ноде, посылает запрос в раббит и ждет от него же ответ и отдает клиенту?

РаббитMQ или kafka позволяют множеству экземпляров вашего сервиса обрабатывать сообщения, с гарантией того, что из очереди ничего не пропадет, и если какой-то экземпляр сдохнет, то этот запрос обработает другой экземпляр. Именно ждать ответ наверное не самое правильное, но это можно смотреть как вам удобнее - периодически опрашивать очередь, или настроить чтобы message service сам пушил по событию.

3. Например делаем микросервис по авторизации пользователя и регистрации. У него должна быть своя база данных? Как например в админке обращаться к пользователям, чтобы их добавить или заблокировать, я должен запрашивать пользователей с микросервиса? Получается микросервис отвечающий за пользователей CRUD + Регистрация, авторизация, сброс пароля?

Это как вы хотите. Если у вас очень много пользователей и авторизация тормозит, но можно сделать микросервис с авторизацией, сделать кластер базы данных с репликацией. Дальше можете балансировать пользователей и там уже решать как их раскидывать. Или база мощная и все экземпляры могут работать с кластером. Или делите базу на части, и раскидываете пользователей по алфавиту (база юзеров от A* до H*, база юзеров от I* до M*, по региону или как вам нравится).

Микросервисы нельзя писать до того как вы представите себе в голове общую архитектуру всего проекта, и какую проблему вы хотите решить.

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

Фриланс - это о то, чтобы быть предпринимателем, искать себе заказчика, договариваться с ним.
Было бы полезно устроиться в компанию покрупнее, освоиться с тем, как идет разработках крупных продуктов.

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

Аргументы:
Если ты сейчас начнешь зарабатывать, и что-то заработаешь, тебе будет хотеться зарабатывать больше. Но без опыта работы в сложных проектах, это будет означать работать больше, а не качественнее. То есть просто упрешься в свой лимит времени, а через 5-10 лет будешь писать о том, как ты перегорел.

Развиваться можно тогда, когда есть достаточно свободного времени.
Подтяни английский на уровень upper intermediate - это много времени и усилий.
Сдай на права.
Подучи на своем проекте что-то серьезное (популярные фреймворки и технологии и сделай серьезный рефакторинг), сделай масштабирование и отказоустойчивость.

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

Самые часто встречаемые проблемы связаны с особенностями файловой системы и прав доступа.
Дальше идет вызов различных консольных утилит и все что с этим связано.

Для решения этих проблем, можно потратить неделю на чтение статей о том как работают файловые системы и права доступа на fat32, ntfs и какой-нить POSIX, например ext3/ext4. Не обязательно очень глубоко, но на среднем уровне мне кажется это полезная и важная вещь для любого айтишника.

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

Является ли каждая игровая сессия, в которой сидит по 10 игроков, новым процессом на сервере? Или это реализовано как-то по другому?

По-разному.
Может быть отдельный процесс.
Может быть отдельный тред.
Может быть вообще один процесс на все.

Зависит от игры, от матча, от требований к быстродействию и синхронизацию.

Погугли
zuntzu

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

Можно шифровать пароли или енв файл целиком и хранить в репозитории, а на инстансе хранить только секрет для расшифровки. Ну и этот секрет можно разок сфотографировать и положить в сейф, менять раз в год или с очередным ажиотажем в СМИ по поводу прогресса в квантовых вычислениях.

Можно пользоваться специальными хранилищами, особенно если пользуетесь облаками или контейнерами - и в кубернетесе и в опенщифте есть возможность хранить секреты.

Можно пользоваться сторонними сервисами, которые вообще управляют вашими паролями, сами их ротейтят, следят за тем кто и когда их запрашивает, типа киберарка.

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

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

Ну или есть еще путь фулл-стек.

Что значит "открыл порт на роутере"?
Куда вы его открыли?
Вам нужно какой-то порт снаружи замапить на ваш ноутбук+порт.
Поищите на роутере port forwarding, это может быть в настройке NAT и замапьте, что например порт 80 мапится на ваш 192.168.0.23:8090

Для бизнес приложений в java есть фреймворки, которые верстают за вас.
Начиная от древних gwt, spring и др.

Могуть дать задание поработать.

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

Прочитайте текст наоборот и скажите, чтобы вы ответили на следующее:

'После двух лет разработки на фронтенде, хотел бы попробовать свои силы в бэкенде, поскольку умение создавать пустые интерфейсы без реального приложения не радуют.
Какое время займет обучиться на бэкенд java достаточно, чтобы устроиться на работу?
Пригодятся ли знания фронтенда по алгоритмам, ООП, паттернам и архитектуре в бэкенде?"