Andrei SunnyPh

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

Может быть и супер сложный clean architecture + DDD + CQRS.
Может быть Vertical Slice.
А может быть и предельно простая архитектура даже без разделения на проекты (крайне недооценённый вариант на самом деле)

У всего есть свои плюсы и минусы.

Русские пейпалы все заблокировали
Если вы переехали жить в Казахстан то просто откройте казахский пейпал это не запрещено

Потому что вы сделали вот там *тыкает пальцем в экран* не правильно, нужно было сделать вот так: *кусок кода*. Вот и всё, проблема решена

const response = axios.post("https://translate.api.cloud.yandex.net/translate/v2/translate", 
  // Это что за новый синтаксис такой?
  json = JSON.stringify(body),
  headers = headers
)

const response = axios.post("https://translate.api.cloud.yandex.net/translate/v2/translate", {
  body: JSON.stringify(body), // В необходимости JSON.stringify тоже не уверен
  headers: headers
})

P.S. В response будет промис в таком случае. Перепишите на async/await

Посредник должен сделать полностью акк на себя (оплата, доки)
В итоге, акк официально не твой(

Я например использую FirstVDS.

Там крутятся несколько net core 3 и пара NET6
Развертывание через дженкинс на моей рабочей машине.
VPS обычная убунта 18

Всегда можно поставить и активировать английскую про, и скачать к ней русский MUI. Еще со времен XP.
Будет полностью аналогичный русской внешний вид и функционал, плюс доп. совместимость, т.к. все локальные системные папки не будут использовать кириллицу.

1. регистрируете ИП
2. создаете сайт пусть на C# NET6
2.1 авторизация через соц. сети + локальная
2.2 для поисковиков Razor pages и или https://yandex.ru/dev/turbo/
2.3 админка на минималках
2.4 апи отображения, используются как в мобильном приложении так и в контроллерах
2.5 оплата через яндекс пай
2.6 подключаете jivo для быстрой связи на сайте
2.7 апи для связи с бухгалтерией
2.8 рабочее место оператора (создание заказа, обработка заказов)

3. мобильное приложение
3.1 авторизация через апи 2.1
3.2 проверка статуса, история, горячие предложения
3.3 интерфейс оператора, просмотр заказов, изменения статуса
3.4 интерфейс пекаря просмотр заказов изменение статуса, каждое изменение статуса отправляет уведомление всем учавствующим в цепочке.
3.5 интерфейс курьера

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

Плевать не от того отталкиваетесь как правильно заметил Сергей Горностаев нам нужны метаданные и статистика итак:

1 выдача куки или любого идентификатора для пользователя, плевать на место мы его поймали и отслеживаем все действия, уже на этом этапе мы смотрим куда он ходит, какие категории просматривает и так далее
2 Он таки созрел и регистрируется, теперь этот анонимный пользователь фиксируется с реальным лицом
3 при покупке выкатываете офферы и скидки, типа добавь дребедень и получи -5%

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

На каждый запрос необходимо создать индекс, некий массив данных, который позволит очень быстро (обычно с трудоемкостью log от количества данных) найти записи, соответствующие связанному с ним запросу (обычно это буквально значение -> список ссылок на записи, часто в виде сложной структуры, например древовидной). Запросы ведь бывают разные, есть простые - просто поиск по значению, математические (суммы, поиск min/max, и т.п.) и текстовые (например наличие слова в подстроке), и на каждый тип может понадобиться свой индекс.

Индексы можно создавать самостоятельно в оперативной памяти средствами языка (например c++, java,.. имеют готовые классы для индексации типа has table или has tree или еще как). Настоятельно рекомендую взять готовый софт - реляционные базы данных, позволяющих очень красиво описать свои данные в виде реляционной структуры, настроить индексы и, пользуясь sql запросами, делать эффективные поисковые запросы.

Открытые и бесплатные mysql, postgres, sqlite (последний очень простой, в виде библиотеки а не сервера а база в виде файла). В подавляющем большинстве случаев открытые и бесплатные инструменты будут более чем достаточны и не будут отличаться по скорости с дорогими платными инструментами, чаще всего они дают прирост в сложных ситуациях, когда есть многопользовательский доступ с одновременной записью, инструменты отказоустойчивости и т.п. в общем все то что в данной задаче скорее всего не нужно.

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

Есть лайфхак, средствами файловой системы включаешь принудительное кеширование записи, т.е. игнорирование команды flush от сервера базы данных.. делать это можно разными способами, тюнинг файловой системы (ext4 journal date write back), виртуальные машины с принудительным кешированием, инструменты самой базы данных (например разместить файл лога т файлы хранения индексов в оперативной памяти) и т.п.