но имхо я бы все таки посмотрел в сторону отдельного сервиса который предоставляет данные раз у вас есть разные презентеры данных

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

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

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

Насколько я понимаю вашу задачу я бы на вашем месте сделал бы отдельный проект ядра. Вынес бы внешние апи и заставил бы старый проект просто дергать это апи. Аналогично и новый. Но это уже ближе к микросервисам. Не знаю надо ли вам оно.

Для read слоя делаю проекции
Тогда они забираются в одном месте

То есть отработала логика
Потом идёт перестроение данных

так появляется разделение хранилищ дял read и write
для Read тогда вообще можно не хранить стейт, а просто поток событий

тут выходят NoSQL решения на передний план

Здравствуйте, Товарищи.
Буду благодарен, за любой совет по теме.

На повестке дня, вопрос:
`
написать чат ( фунукционал телеграмма, с самой важной фичей - 100% доставка сообщения  даже когда один/много людей из чата/чатов оффлайн + другим сопутствующим функционалом )
`

Вариант с centrifugo, отпадает, так как centrifugo не гарантирует 100% доставку.

С асинхронным php(swoole/reactphp) не сталкивался.

Был ли опыт реализации на PHP, в связке с чем то, что могло бы гарантировать 100% доставку ?
Есть сомнения, что стоит посмотреть в сторону Golang.

Ничто не гарантирует доставку

Только ответ от клиента что такое то сообщение принял

Это может быть реализовано на чем угодно

В любом случае сервер может упасть и т.д. 100% это мифическая цифра

это понятно, но с примерным процентом reliability+-  как у телеги

А какой у телеги?

телеграмма/slack

система должна выдерживать в минуту 5К коннектов минимум, ожидать ответ от клиента оверхед.