Сергей Протько

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

Именно так. Я бы даже сказал годика так 3 хотя бы, и пару десятков разных проектов. Важно что бы вы получили разный опыт.

Неужели чтобы написать даже самую простую CMS для личных элементарных нужд придется изучать куча всего другого чтобы выстроилась точная картина о ее разработке?

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

но интерес составляет написать самому

Начните с фреймворка:

- библиотека для рендринга шаблонов (буферизация вывода, работа с файловой системой немножко)
- библиотека для маршрутизации запросов (прошаритесь в регулярках)
- библиотека для работы с базой данных (не ORM, начните с Table Data Gateway или DAO хотя бы. Прошаритесь в SQL минимально).
- Ядро, связывающее все это вместе. Желаельно с какой-то концепцией мидлвэров, что бы все остальныекомпоненты ничего не знали о ядре. (прошаритесь в HTTP)

В целом же писать CMS очень и очень скучно и долго. Вы намного быстрее прошаритесь во всем что надо делая отдельные компоненты. Благо сейчас век composer-а и вы можете крутить и вертеть фреймворками как хотите, подменяя чужие компоненты на свои.

С каким бекендом Вы предпочитаете связывать свое приложение?

Обычно REST/HTTP API/RPC прячут нюансы реализации бэкэнда. Так что без разницы, лишь бы апишка была удобная.

Каков Ваш стек в этом плане?

php, symfony2, postgresql. В любом случае разработчика SPA это волновать должно в последнюю очередь.

Так же интересует выбор баз (MySql, MongoDB....)

никогда не используйте mongodb как основное хранилище. Любая реляционная база на простых задачах (а на простых задачах nosql не нужен) будет проще и эффективнее. Говорю это основываясь на своем горьком опыте. Храните в mongodb агрегации денормализованных данных для ускорения выборок из реляционок. то есть в mongodb должны быть либо простые независимые данные (логи например) либо read-only данные.

Собственного сервера нету, поэтому Node.JS не катит.

ну у вас же есть сайт? Значит есть возможность организовать API к базе данных.

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

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

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

дешифровка

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

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

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

К нему будут подключатся другие сервисы где нужна авторизация

А зачем им то подключаться? вы ж микросервисы ваяете, вам zeromq надо а не давать доступы к key-value хранилищам которые использует сервис авторизации. Так вы создательно усложняете последующее масштабирование этой части системы.

хоть петабайты данных

Петабайты данных в реляционках никто не хранит, как минимум потому что такие объемы нет смысла хранить. У вас только логи могут быть такими, весь хлам потом можно будет скидывать в какую-нибудь кассандру (эпл в ней 4 петабайта инфы хранит).

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

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

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