Архитектура не настраивается.
Архитектура создается, разрабатывается.
Присоединяюсь к
DevMan вопрос из серии "я не знаю чего хочу, но мамой клянусь будет круто, помогите".
учитывая что нагрузка на проект со временем будет расти и нужно будет думать о масштабировании (например репликация).
Репликация не для собственно масштабирования, а для надежности. В ответственном проекте следует сделать репликацию сразу. Даже пока нагрузки нет.
Существует 2 пути:
Горизонтальное масштабирование, и вертикальное масштабирование.
Вертикальное масштабирование гораздо эффективнее использует железо до тех пор, пока железа хватает в лице одного единственного сервера. Да, все части ставить на один сервер.
Горизонтальное масштабирование подразумевает организацию взаимодействия между разными серверами. Но на которых у вас вовсе не СУБД на одном, а бекенд на втором.
А когда у вас множество СУБД, множество бекендов, размещенных на разных серверах.
И простой репликацией вы тут не обойдетесь. Понадобится как-то организовывать взаимодействие между этими частями. Типично - через MQ.
Таким образом, если вы сразу планируете дичайшие масштабы, с которыми не сможете справится на одном-единственном сервере - то вам сразу нужно так делать, чтобы могли свободно увеличивать количество бекендов и СУБД и при этом они не мешали друг другу.
Типично:
На какой бекенд будет отправлен очередной запрос? Нужно или sticky session или полное отсутствие состояния на бекенде (а второе плохо для производительности).
Типично:
Репликации? Ха. Репликация мастер-мастер - тот еще гемморой. А репликация master-slave подразумевает, что на запись у вас нагружна ровно одна СУБД.
Далее:
Удалось справится со всем этим, горизонтально масштабируете отлично. И вот у вас уже десятки серверов. Чем больше железа - тем больше падений, тем больше service discovery. И как вы это будете разрешать? Ручками? Значит придет пора подумать об оркестрации.
И т.д. и т.п.
Имхо, поскольку вы вообще не представляете во что ввязывайтесь, - используйте просто вертикальное масштабирование на одном сервере. И репликация как подмога к резервному копирования.
Разделять СУБД и бекенд стоит с умом. Ибо это сразу увеличивает накладные расходы на каждый вызов. Добавляется сеть между СУБД и бекендом. Если вы не понимаете еще зачем разделять - то не разделять.
Сложный
