index0h

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

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

отсутствуют навыки декомпозиции и решения задач, не развито алгоритмическое и логическое мышление.

Определите сущности, которыми будете пользоваться. Например, нужно сделать чат. Какие сущности данных у вас могут быть? Наверное Пользователь, от имени которого будут отправляться Сообщения. Сообщения будут отправляться в Каналы. У каждой сущности есть какой-то свой набор данных.

Далее определите действия, что вы можете сделать с этими сущностями. Под эти действия заводите сервисы.

Понимание того, как лучше будет приходить с опытом, причем не только вашим личным, но и командным.

Лучше всего подходит язык, на котором у вас есть експертиза.
Но сначала стоит сконцентрироваться на постановке задачи. Жанр и мультиплеер - это конечно круто, но мягко говоря недостаточно, но это как описывать устройство автомобиля по цвету пластика дверной ручки.
1к играков - это тоже довольно абстрактное значение. Какой трафик и как его обрабатывать/хранить/передавать другим игракам - вот это задача.

Похоже на БД. Посмотрите нагрузку цпу/рам/то на сервере с БД. Так же не лишним будет посмотреть лог медленных запросов и процесс лист. Если наблюдаются сильные тормоза при вставке, посмотрите загруженность буфера бд.

Угу, за счёт его не открывания. В случае, если вы не изменяли файл и не отключали opcache, ваш файл будет читаться один раз, потом браться из кэша.

7.2 - древняя версия, официально не поддерживаемая. Хотя бы 8-ку установите

Это полностью проекто зависимая штука. К микросервисам стоит выростать из монолита. Микросервис по хорошему должен покрывать полностью конкретный домен, но им же и огранививаться. Вот тут как раз и кроется сложность. Если вы никогда не реализовывали проекты конкретной области, вероятнее всего вы разделите микросервисы не правильно, что усложнит и удорожает поддержку. В худшем сценарии ваши микросервисы будут чем-то вроде REST вокруг таблички в БД.

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

Пример плохого разделения для задачи отправки писем по событиям (регистрация, новости, маркетинг...):
Сервис_А подготавливает данные и дергает Сервис_Б, что бы тот запихнул их в шаблон и отправил почту.
Подход плохой потому, что каждое новое сообщение требует изменений И Сервис_А И Сервис_Б, причем синхронизированных.

Та же задача, но с более лучшим решением:
Сервис_А отправляет события в стиле "юзер зарегался", "юзер сделал покупку",... Сервис_Б самостоятельно решает, что и когда отправлять ползователю.
В этом случае Сервис_А и Сервис_Б зависят друг от друга по минимуму.

По хорошему лучше так не делать. Разбор синтаксического дерева - это довольно сложная задача и ее стоит решать в крайнему случае.
Я бы рекомендовал ввести по полю на все ваши возможные фильтра и уже их использовать для построения запроса. Например: id (id = ), amountFrom (amount >=), createdAtFrom (createdAt >=),... Каждый фильтр объединяет в себе операцию и поле табицы. Да, прийдется перечислить все ваши поля и операции, но это решение самое простое в поддержке.

Так же вы можете передавать массив фильтров, в стиле: [field, operation, value].
На этапе обработки вы сможете относительно легко проверить и название поля, и операцию (>,<,=,!=,...), и заэкранировать значение. Вложенные условия будут уже сложнее.

Объект Request по хорошему стоит воспринимать как иммутабельный и вообще не производить с ним ни каких изменений. Установка кук - это задача Response. Жабы отдельно, гадюки отдельно.

Всем привет. Хочу сделать пошаговую регистрацию на сайте. Как бы это сделать правильнее?

Если есть возможность - просите минимум, например почту и пароль, в идеале - вообще через google, или еще что-то подобное, fb например.
Уже потом запрашивайте данные которые вам нужны для конкретных действий.
С точки зрения пользовательского опыта вероятно это будет самый лучший сценарий.

1. После каждого шага сохранять в БД? Много запросов бессмысленных

Оптимизируйте там, где есть узкое горлышко, а не там где его нет.

2. Хранить в сессии?
3. LocalStorage?

Вам стоит точно решить, как вы взаимодействуете с фронтом. Если это грубого говоря отдельное приложение с каким-нить rest или подобным взаимодействием - LocalStorage, или SessionStorage. Если старый добрый серверный рендеринг - сессии.

4. Куки?

нет.

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

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

C нуля если у вас не завалялось несколько лямов вечено зеленых инвестиций, даже начинать не стоит.
Как альтернатива - можете посмотреть в сторону Onlyoffice, правда там не точто Yii2, там даже про php думать не стоит.

Чем меньше логики на стороне БД вы будете держать - тем проще вам будет с этим жить

Гуглите на тема inotify