Денис Сепетов

Поддержу Ипатьев. Вы хотите избавиться от 3-х запросов, чтобы что? У вас реально база рухнет от 3 запроса × на 10 регистраций в день?

Можно конечно и на клиенте хранить, но смысл? Как минимум нужно валидировать каждый шаг. Вот прошёл юзер 10 шагов, отправил данные, а у вас fatal error на беке, такой email уже есть в базе. Усложняем логику в 10 раз, отправляем клиента на шаг #22, где он мыло вводил?

В общем это не оптимизация, это выстрел себе в ногу на ровном месте. Ещё и юзера бесить будете

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

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

Как конкретно ведётся разработка - это уже на откуп команде. Подход легко может различаться исходя из языка/платформы.

Если задача уже в работе, то её не остановить стандартными средствами Yii.

Вы удалили задачу из очереди, но она уже в работе. Пока задача не выполнится, консьюмер будет работать.
В случае с while (true) echo $i++; задача никогда не выполнится.

Мое решение:
Отнаследовался от redisCommand

use yii\queue\redis\Command;

class RedisCommand extends Command
{
    public function actionRun($channel = null)
    {
        if ($channel !== null) {
            $this->queue->channel = $channel;
        }

        return $this->queue->run(false);
    }
}

Подключил его в консольном конфиге

'queue' => [
            'class' => \yii\queue\redis\Queue::class,
            'commandClass' => \app\commands\RedisCommand::class,
            'redis' => 'redis',
            'channel' => 'default', // Queue channel key
            'as log' => \yii\queue\LogBehavior::class,
        ]

В консоли одноразово
yii queue/run channel_group_1

Для listen аналогично переопределите метод actionListen, только канал вторым параметром
Команда будет выглядеть
yii queue/run 3 channel_group_1

Хранить html код в столбце поста кажется нецелесообразным по ряду причин:

Угу, ага...

Лишняя трата памяти на хранение html тегов

Ого, а лишние это сколько? Экономия на байтах чаще всего приводит к тратам на вычислительные мощности. Некоторые расчеты чуть ниже.

Уменьшение производительности (?)

Производительности чего?

Стили/компоненты могут изменяться, а код останется прежним

Стили как раз и нужны для того, чтобы легко конфигурировать визуал, не привязываясь к коду. Код может быть каким угодно, но стилизация через теги пока что лучший вариант, который придумали разработчики.

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

Ага, переизобретаем BBCode, найс... Для понимания проблемы - такие коды придуманы для форумов, с целью ограничить использование хтмл в пользовательском вводе. При этом подходе он худо-бедно оправдан, хотя и требует постобработки при каждом выводе, а это использование регулярок, что как бы совсем не бесплатно. В вашем же случае, источник текста более-менее доверенный, и ограничение в тегах больше мешает чем помогает.
Что касается экономии на "минифицированных" тегах, ну допустим сэкономите вы 100 байт на тегах, то есть на 1000 постов экономия будет.... ТА-ДАААМ! 0,1 мегабайта! А если экономия 1000 байт на пост, то целый МЕГАБАЙТ можно сэкономить! Похвальная рачительность.

Хранить каждый элемент поста отдельно в бд со следующим содержанием (element_name, position, content, post_id), используя отношения к родительскому посту, соответственно сохранится структура и рендериться пост будет через соответствующие компоненты в нужном порядке (однако как будет именно рендериться в шаблоне поста пока неизвестно)

Базовые элементы и так должны храниться отдельно, другой вопрос почему они у вас рендерятся в одном порядке, а в другом месте в другом порядке? Заголовок, короткое описание, текст, главное изображение - отдельные поля, оглавление по сути часть текста, зачем его выносить отдельно - загадка, это же такой же текст, котрый автор волен располагать . Вариант с внешней таблицей по сути приводит нас к выносу части данных в EAV(отличный пример универсализации в ущерб производительности), что как раз будет серьезно напрягать выборки бд, если понадобится делать какие-либо поисково-выборочные манипуляции по этим данным.

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

20 лет назад этот вопрос был полнонстью решен с помощью технологий XML/XSLT/XPath.
Языки C#/dotNet, Java поддерживают этот стек. И много других языков и библиотек.

Потом еще создавали более простые вещи. Шаблонизаторы. Velocity, FreeMarker. Они немножко
переворачивают постановку. Но их тоже можно рассмотреть.

Хранить html код в столбце поста кажется нецелесообразным.

С точки зрения суммарной стоимости владения (TCO) база данных всегда будет дороже
чем файловая система. А самым дешевым будут хранилища типа Amazon S3, MS Blob, G-Drive.
Ну если пересчитать удельно сколько стоит гигабайт.

Хранить каждый элемент поста отдельно в бд со следующим содержанием (element_name, position, content, post_id),

Тут - непонятно. Но есть такое эвристическое правило дизайна
хороших NoSQL систем. Все данные для запроса должны лежать физически рядышком
и не требовать дополнительных действий. В идеале - для отдачи поста вы должны сделать
один единсвтвенный SELECT без joins и без подзапросов и агрегаций и без CONNECT-BY.

Вообще то в Yii2 есть замечательная вещь как фильтры. Вам нужен VerbFilter. Курить мануалы тут: www.yiiframework.com/doc-2.0/yii-filters-verbfilte...

Но не знаю, какое техническое решение взять? Писать на нативном РНР? Взять готовый фрэймворк?

Что знаете, на том и пишите.

Если Вы задаёте вопрос про "фреймворки или нет", значит Вам темболее необходимо использовать фреймворк. Свой велосипед Вы в любом случае напишите хуже.

Если Вы не разработчик, то наймите ПМ или разраба, он Вам и сообщит, на чем именно он будет писать.