Айдар Хаятов

Используйте событие load.
window.addEventListener('load', handlerFunction)

https://sequelize.org/v5/

SEO продвижение основная задача - поэтому SPA не можем применить.

Странное утверждение, учитывая, что SPA-сайты без особых проблем можно рендерить на сервере для первоначальной загрузки. Для поисковых систем такой сайт ничем не будет отличаться от любого другого. Если SPA на React, то все подобные проблемы решает NextJS. Вот пример сайта на NextJS. Для других фреймворков тоже есть готовые решения для SSR (server side rendering).
SPA + SSR полностью решает Вашу проблему.

Мы используем вот такой подход. Покажу на примере action из redux, но его можно использовать и с компонентами.
Создаеться файл index.js в директории с shared компонентами. Из него экспортируются все именные экспорты из файлов в этой папке вот таким образом:

Файл index.js:

export * from './auth';
export * from './user';
export * from './interfaces';
export * from './search';
export * from './catalog';
export * from './classifier';

Файл auth.js:

export const getUserToken = ( login, password ) => (dispatch, getState) => {...}
export const registerUser = ( newUserData ) => ( dispatch, getState ) => {...}

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

import { getUserToken, doSmsng, doSmsngElse } from '../../../_actions';

У mapStateToProps есть второй аргумент - props компонента, доставайте id оттуда:

(state, ownProps) => {
  const { projectId } = ownProps.match.params;
  ...
}

location / {
        rewrite ^/(.*)$ /1.0/index.php last;
    }

Архитектура не настраивается.
Архитектура создается, разрабатывается.

Присоединяюсь к DevMan

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

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

Репликация не для собственно масштабирования, а для надежности. В ответственном проекте следует сделать репликацию сразу. Даже пока нагрузки нет.

Существует 2 пути:

Горизонтальное масштабирование, и вертикальное масштабирование.

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

Горизонтальное масштабирование подразумевает организацию взаимодействия между разными серверами. Но на которых у вас вовсе не СУБД на одном, а бекенд на втором.

А когда у вас множество СУБД, множество бекендов, размещенных на разных серверах.

И простой репликацией вы тут не обойдетесь. Понадобится как-то организовывать взаимодействие между этими частями. Типично - через MQ.

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

Типично:
На какой бекенд будет отправлен очередной запрос? Нужно или sticky session или полное отсутствие состояния на бекенде (а второе плохо для производительности).

Типично:
Репликации? Ха. Репликация мастер-мастер - тот еще гемморой. А репликация master-slave подразумевает, что на запись у вас нагружна ровно одна СУБД.

Далее:
Удалось справится со всем этим, горизонтально масштабируете отлично. И вот у вас уже десятки серверов. Чем больше железа - тем больше падений, тем больше service discovery. И как вы это будете разрешать? Ручками? Значит придет пора подумать об оркестрации.

И т.д. и т.п.

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

Разделять СУБД и бекенд стоит с умом. Ибо это сразу увеличивает накладные расходы на каждый вызов. Добавляется сеть между СУБД и бекендом. Если вы не понимаете еще зачем разделять - то не разделять.