Saboteur

Все обучение без практики - ничто.
Практика без смысла - демотивирует.

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

Axel SWAT,

Что ещё?

Зачем что еще?
Вам поиграться или ехать?
Задача сделать магазин - сделайте. Если что еще, то совершенно несложно взять ваш магазин и позже перенести его куда угодно. На тот же НАС, на aws на селектел, на виртуалку, в контейнер, вариантов полно, и тут даже сложно прямо сказать какой из них лучше или хуже - все зависит от ваших навыков.
Учитывая, что навыков видимо не достаточно, то просто берите хостинг.

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

В опен-сорсе обычно очень маленькое количество огромных комбайнов. У вас тут хотелки на 5-6 отдельных продуктов. А все в одном бывает в основном в крупном ентерпрайз продукте, типа комбо от atlassians, или какой-нить битрикс.

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

Арендуйте виртуальную машину и делайте там столько портов, сколько угодно.

Нормальная практика, но это зависит от задачи.

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

А вариант, когда один сервис пишет, другой активно читает, третий периодически делает какие-то отчеты, четвертый просто мониторит - вполне себе норма.

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

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

Разделить разработку и поддержку.

Разработка - на тестовом енвайрнменте с тестовыми данными
Поддержка - ограниченным кругом доверенных специалистов.

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

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

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

Совсем другой вопрос что дейсвительно существует море "усложнятелей", но об этом полно и анекдотов и реальных историй. Так что в данном случае нужен архитектор или грамотный менеджер, который понимает и необходимости бизнеса, чтобы работать и адаптировать ТЗ, и понимает риски со стороны технологий, чтобы выбирать или одобрять на чем будет это все написано, где хоститься и так далее.

Даже по названию папки понятно откуда она так называется. public слово понятно, html понятно.
Дефолтные настройки веб сервера для персональных страничек пользователей.
При включении они доступны по адресу www.site/~username

так и называется oauth.
Выдача токенов.
Обычное апи для авторизации + документация как ваше API использовать и интегрировать в другие сайты

web api, это api по веб протоколам (обычно http/https).

1. Под капотом скриптом написанном на JS(+CSS) одни элементы прячутся, другие отображаются.
2. При помощи того же JS идет обращение к сайту по API и запрашивается необходимая информация (технология называется ajax).

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

конечно в базе данных.

Начал практиковать qt, но как я понимаю написание дескоптных приложений на плюсах - такое. Тогда хочу попробовать разработку ПО, cофтов, драйверов и тд. Что можете посоветовать по изучении этой темы?

Что значит "такое"? Сложно, долго, неудобно?
Так да, программирование это не тяп-ляп и готово, это долго, скучно, неудобно.

Что такое разработка ПО и софтов по-вашему? Или десктопные приложения это не ПО и не софт? А что тогда?

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

Скачать страницу не браузером.

Ну то есть? Берешь и рисуешь колокольчик, если для юзера есть непрочитанные новости.
Алгоритм чего? Отрисовки надо или как gif колокольчика вставить?

Или (вруг) ты не знаешь про cookies?