Saboteur

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

В целом, компонент достаточно самостоятельная сущность, которую можно либо использовать независимо, либо легко интегрировать.
Модуль - явно часть чего-то, что не может существовать без основного продукта (например плагин). В этом случае он не столько интегрируется, сколько сразу подключается, а существовать самостоятельно не может.

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

Странный вопрос.
А где сейчас хранишь информацию об одном боссе?
Там же храни и про нескольких.

Архитектура строится исходя из
1. как это будет запускаться, на каких ресурсах, хватит ли 1-2 cpu сейчас или через год, если надо будет масштабировать?

2. Опять же сколько данных будет через год или 5 лет, будут ли они обрабатываться также быстро?

3. Надо будет обновлять софт - ОС, версию java или еще чего. Насколько удобно и легко это будет делать

4. Нужно ли вам работа 24/7, или можно отключать систему по ночам или выходным для различных технических требований (апгрейды, бэкапы, миграции)

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

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

bash отлично справится

find . -name "file.ext" | xargs -n 10 -P 10 "phraze"

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

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

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

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

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

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

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

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

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

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

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

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

Предполагаю, что хранится diff разница между изменениями.

нет

Возможно плохо искал, но к сожалению, не нашёл подобной информации

Да блин, git вообще opensource, можно все про него найти. И в официальной документации достаточно написано.
да и банально, если почитать пользовательские команды по работе с отдельными объектами, все становится понятно. Повнимательнее полазь по каталогу .git

А знать надо - немного про работу с файлами.

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

консоль и гуй - это просто интерфейсы для работы с чем-то - с пользователем или с другим ПО.
консоль - максимально простой и универсальный интерфейс, который можно потом быстро прикрутить куда угодно. А GUI - в основном только для пользователя (он и расшифровывается как Graphic USER interface)

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

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

Для записи можно использовать UML

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

Работа с данными прямо из doc документа для новичка будет непросто.
Как минимум нужно список вопросов и правильных ответов перенести в более удобный для программы вид - массив, базу данных, или хотя бы простой текстовый файл с разделителями (CSV)
А так - проще всего будет сделать на php с веб-интерфейсом.
Если хочется именно десктопное приложение для винды - лучше c# чем c++

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

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

Нужно научить человека стать опытным специалистом. Есть идеи, как это в принципе делать?
Получение опыта - длительный процесс. Занимает всю жизнь, поэтому кто-то вас всю жизнь учить не будет.

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

influxDB больше подходит для хранения числовых метрик, чем строк, и уж тем более, чем комментариев. В этом она одна из лучших. И выборки по таблицам, там нет, даже собственно таблиц с колонками нет, есть метрики, которые хранятся скорее в виде объектов. Вот хранить данные по нагрузке,трафику, другие числа и иногда строки - это да.

Но если вам нужны выборки по таблицам, оставайтесь в пределах SQL баз.

Архитектуру разбиваете на части:

Хранение информации о фруктах и собственной самой змейки
Логика движения змейки
Управление
Визуализация (отрисовка, которая может выполняться в зависимости от устройства, например с разным разрешением).
Отдельно - меню запуска и может быть, например, таблица рекордов.
Может быть даже таблица рекордов с передачей информации в интернет, для глобального рейтинга.

Почему нельзя сделать простенькую систему на php + js + mysql, и не городить "большую систему".
Просто потратьте деньги, наймите студию которая напишет вам приложение раз и навсегда.