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

надо просто разделять онлайн и оффлайн.

А что такое "паблишер" и кто на него отдает события? Тут, похоже, календарь, т.е. события привязываются к датам и, иногда, возникают в текущий момент (личные сообщения). Тут паблишер не сильно поможет (и не понятно, что будет при его падении).
А при общих очередях все гарантированно достанется клиенту (рано или поздно)

Вот пользователь онлайн, но данные из ws не выгребает. Что делать?

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

Что значит "не выгребает"? Я в сокет положил, они к нему полетели. А если ack не прислал - значит в оффлайне и рвем соединение.
Если нужна гарантия обработки на той стороне, то только через ack, увы.

online - это и значит, что события обрабатывает (в данном случае)

Паблишер - я имею в виду просто процесс который получив событие, разбирает кому оно должно быть доставлено и пересылает в вебсокет. Если он падает... ну блин :) - процесс читающий события из БД тоже может упасть. В общем - разные подходы - тут нужно более детальные требования

А откуда оно получает события? Из той же БД из тех же очередей с событиями по дате же.

Если процесс чтения событий упал - ну и что, после подъема пойдут отправляться те же события, все же транзакционно )

Я бы поднял 20 воркеров поверх БД и на каждом ждал ack 100ms, если не получил - то в оффлайн, если получил - берем следующее.
Это даст до 200 событий в секунду и не слишком нагрузит БД. Для этих НФТ - нормально.

(Хотя что там в питоне с поднятием кучи воркеров в разных тредах - не знаю)

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

Всё просто: у нас буфер на сервере, буфер на клиенте и между ними перемычка в виде сети. И на этой конструкции строится flow control в tcp.

Клиент на медленном канале, а доставить ему надо 100500 уведомлений. Сервер часть этих данных в буфер положил, а по сети оно частично доехало до клиента, а дальше мы ничего послать клиенту не можем, потому что flow control. И это ещё не касаясь вопроса "а если нам нужно подтверждение что уведомление прочитано"

Почитай постановку - там единицы сообщений в секунду, не будет 100500. Латенси бывает длинное, но не настолько.

(Т.е. и настолько, но тогда проще или уйти в оффлайн или поднять таймаут доставки)

клиент - мобилка и свалилась в edge ;)

Тут объем не существенен, только латенси.

Т.е. даже 1kb/s уже норм нотификации прокидывать )

Для мобилки никто сокеты делать не будет. firebase и пуши, пусть гугол/эппол разбирается с доставкой. Я не мобильный разработчик, но вроде у них это так работает.