Судя по данным, которые мы получили, лучшее решение
https://g.zeos.in/?q=highload%20push%20service%20architecture

Мне базовую архитектуру понять, чтобы начать копать в нужном направлении.
А вообще задача такая: реализовать сервис, который будет отправлять сообщения из кафки мобильному приложению по веб-сокету.

И где вопрос? Вам нужен косюмер который шлет по сокету запрос

Вопрос в том может кто когда то делал подобное или подскажет куда копать?
Ссылка выше у меня открывается.

Да в смысле куда копать? Делаешь сервис, кладешь в папку services
Давайте более конкретные вопросы

а что копать?
function consume(Message $message) {
$this->webSocket->send($message);
}

Ну вообще есть такая идея для реализации: консьмить сообщения из кафки в бд, затем пуллить из этого бд сообщения для всех веб-сокет соединений. Раз в день удалать записи из бд. Как думаете норм идея?

И зачем тут цепочка бд?

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

И?

Вы решайте проблему по этапам, если нужна гарантия доставки по сокету, есть один лайвхак
https://g.zeos.in/?q=websocket%20guaranteed%20delivery

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

Можем пойти другим способом.
Заходите на google.com
Вводите в строку поиска websocket guaranteed delivery

@artcorp96, а есть еще подобные сайты?
Спасибо что помогаете)

Велком, всегда ваш кэп.
Такие сайты? Поисковики что ли?

Попробую по другому.
Сейчас у нас такая реализация:
Есть сервис который читает сообщения из кафки и хранит не доставленные сообщения у себя в памяти пока действует ttl. Отправленые же сообщения он удаляет после получения потверждения о получении от клиента (гарантийная доставка).

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

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

Гуглил, но мало че нашел.

хочется хранить в бд - храните в бд. А кафка вам тогда зачем?

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

Возможно там есть какое-то ограничение, но не могу его уловить.

Пуши не гарантируют доставку:)