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

Кафка здесь как персистентное хранилище для всех сообщений пользователя с возможностью подписки

> всегда выполнялись обычным хранилищем
вот про это можете раскрыть?
Что имеете ввиду, какой-то паб/саб из бд? Или сначала отдаем данные из бд, а затем новые события из кафки?

Второе. Все нотификации идут в основное хранилище и, если пользователь онлайн, в брокер.

> единая точка

йеп, при таком раскладе у вас должен быть микросервис нотификаций, занимающийся этими делами

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

Всем привет! Поделитесь опытом, пожалуйста. У нас на проекте используется Кафка, клиент на Java.
Есть задача отправлять эвенты клиентам по Server Sent Event. После подключения клиент должен получить все эвенты пока он был оффлайн, а затем продолжать получать сообщения, созданные после подключения.
Хочу реализовать следующим образом. Продюсеры, которые хотят уведомить клиента, отправляют сообщения в специальный топик. Когда клиент подключается, создаем нового Кафка консьюмера на основе id пользователя(каждый пользователь это отдельная консьюмер-группа), подписываемся на все партишены в топике. Затем запрашиваем батч сообщений из Кафки, отфильтровываем сообщения для клиента, отправляем их по SSE, затем фиксируем оффсет в Кафка и так до бесконечнеости. Если клиент отключается, то просто отписываемся от всех партишенов. Простой тест показал, что при 2 партишенах прочитать 1500 сообщений пользователя из 3 млн сообщений в топике одним консьюмером занимает примерно 1,5 - 2 мин, что не проходит по требованиям. Поэтому хочу увеличить количество портишенов(например, до 1024) У нас продюсеры  роутят сообщения по ключу. Консьюмер будет делать предположение в каком партишене искать сообщения на основе ключа и подписываться только на этот партишен.  

Есть такие вопросы:
1. Насколько плохо иметь большое количество консьюмеров с точки зрения Кафки. Допустим, их будет параллельно более 1000 на этот топик?
2. Вывезет ли Кафка такое количество партишенов и консьюмеров?
3. Есть в описанной схеме что-то что я не учел или можно сделать лучше?
4. В схеме с фиксированным количеством партишенов есть проблема, что нельзя будет их увеличить потом так, чтобы не потерять сообщения пользователя. Как бы это можно было бы решить?

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

Посмотри в сторону редиса

Спасибо, почитал доки. У подхода с паб/саб Redis есть недостаток - если пользователь активен, получает сообщение, если нет, то он их уже не получит. И в целом не очень надежно. Также нашел инфу про Redis Streams, получается своеобразная альтернатива Кафка, но держать в одном проекте зоопарк технологий с перекрывающимся функционалом не хочется.