Pavelsha

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

Верно, но не совсем. У конкурентов из выдачи нужно было скопировать все возможные нюансы + улучшить их на пару процентов, а не только СЯ.

В связи с этим есть вопрос: целесообразно и возможно ли переделать всю структуру сайта? У страниц же будут другие адреса, будет путаница в индексации и множество ошибок.

Целесообразно. Переделывайте структуру, а на новые адреса со старых ставьте 301 редирект.

Или проще сделать новый сайт на новом домене?

Как хотите, но я бы решал по 1 задаче за раз.

Смотри. Уже прошло время когда все пилили монолиты на микросервисы. Щас пошло переосмысление.
Объективно есть 2 причины пилить. Первое - организационная. Команда по какой-то причине не хочет
или не может поддерживать приложение. Или там что-то с бизнесом. Слияние. Поглощение. Передача
проекта другой команде в поддержку. Тогда берут и ставят задачу раздела отвественностей.
Конвей про это писал еще.

И второе - это баланс нагрузки и децентрализация. Про failover тут еще даже речи нет. Это
тяжелая тема и распилить монолит так чтобы его части были отказоустойчивы очень трудно. Более
того в случае синхронных взаимодействий между частями микросервисов может быть даже падение
перформанса. Да. Теоретики которые там пишут восторженные отзывы - совершенно игнорируют
накладные на RPC. И не упоминают что в монолите цена RPC была равна нулю. Иногда RPC заменяют
на MQ - но это новая архитектура и это надо полностью переделывать бизнес.

И что делать с базой данных? Это тот еще вопрос. Я почти готов спорить что вы базу пилить не будете.
И что в результате будет? Иммитация микро-сервисов? Где слабая связность?

Тоесть если у вас нет таких кричащих ситуаций что оргазниация требует или нужно баланс
нагрузки как-то разнести - то тебе вообще-вообще нет смысла ходить ни в какие микросервисы.

Но имеет смысл сделать модуляризацию монолита. Например что там...

application
- sales
- hiring
- userprofiles

Тоже очень полезно для управления сложностью. И пускай себе будет монолит зато будет сильный
контроль за изменениями.

При данной схеме тебе база и крон вообще не нужны. Пиши сразу в Rabbit. Если consumer обладает логикой неуспеха обработки - то пускай кидает необработанное вообщение в специальную мусорку (Dead-Letter-Quee) для анализа ошибок впоследствии.

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

На этот вопрос невозможно ответить. Цифры могут отличаться в разы в зависимости от выбранного железа. Но современные MQ настолько быстрые что с большей вероятностью твой софт не сможет их загрузить событями.
Узким местом в такой системе будет скорее всего твой софт.

https://stackoverflow.com/questions/9566862/psexec...

PsExec.exe -s -d -i 2 c:\temp\MyServer MyConsoleApp.exe

Nuitka the Python Compiler

Обычные картинки на фоне.
Фоны могут быть множественными.
Фоны могут позиционироваться.
Плюс медиа-запросы для корректировки.

Если документация есть, то это уже хорошо.
Значит, нужно обратиться к тому, кто эту документацию написал.
Здесь, конечно же, важно, насколько тот субъект заинтересован в том, чтобы документация была тебе понятна вообще. Может быть, это документация для внутреннего пользования, а к тебе она попала случайно, или что-то в этом роде. И даже если заинтересованность есть, может не быть времени и других ресурсов, чтобы тебе что-то объяснять и организовывать уроки.
В последнем случае придётся либо самому изучать вещь и даже составлять документацию по ней. А почему нет? Документацию тоже люди пишут. И обратный инженеринг никто не отменял ещё, он существует как явление. Либо отказаться от этой вещи в пользу другой вещи, которая более понятна, более документирована, и её авторы больше заинтересованы в создании уроков и прочего, чтобы сделать свою вещь популярной.

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

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

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