Во, да, точно.

Согласен, но это сильно связанные понятия же.

Понятно, что есть стэк оборудование-драйвер-ядро-память.

и ещё тупо расстояние

Ну 0.7с в оптоволоконе никто не отменял, да.

Не сильно. Можно иметь 1ТБ/с, но при этом задержку неприличную просто, которую вам даст расстояние и сериализация/десериализация. Скорость света никаким мультиплексированием на тёмных волокнах не обойдешь.

Я с этим согласен. Быстрое всего возить данные по железной дороге вагонами ссдшек)
Но вроде как если девайс подключен на шину DMA и ядро общается с ним напрямую, то сериализация на сетевом стэке не нужна.
Точнее она там сильно быстрее может быть, чем гонять по PCI express даже.

Плюс задержка на канале ну... 3000 / 0.7с... что-то не сильно много получается. Мне кажется, что можно посмотреть в эту сторону попристальнее.

А трасс дальше 3000 км у нас не сильно много.

Про вагон ссдшек пример очень правильный, скорость бешеная, но и латенси на передачу зашкаливает. SerDes будет не на сетевом стеке, а на смене сред передачи (эл. сигнал - оптика).

Не только там. Но да, я это понимаю.

Нет никакой шины dma.  Есть pcie(который внутри тоже пакетная сеть) и все остальное уже поверх pcie.

Есть редкие исключения, но они вроде как умерли :)

Хм. Приму к сведению и перепроверю себя.

Добрый вечер.
Разрабатываю что-то типо системы уведомлений. Фронт React+Redux, бэк Python/+-Rust, есть некоторый опыт с кафкой.
Нарисовал в голове примерно такой сценарий: при входе пользователя на сайт открывается вебсокет, по которому к нему приходят уведомления за время его отсутствия в формате, например, "ещё можно сделать", "нужно сделать сейчас", "пропустил" - это распределяется при подключении в выборке из очереди уведомлений. Далее посетитель должен получать постоянные уведомления, связанные с его группой/организацией/сущностями/индивидуальными настройками, хз, вход с телефона мб или ещё что-то. Вопрос: как такое строится и управляется?

Я думал над чем-то типа того, что после подключения к вебсокету мы должны забрать из некоторой "очереди" то, что застоялось, а потом перейти к обработке потоковой информации. К тому же должен быть кто-то, кто очередь наполняет, либо это просто данные из базы. Думалось, что должен быть один продьюсер, который просыпается раз  в N времени, делает запросы в базу, считает время до некоторых событий и дальше уже через, например, кафку, рассылает эти события по каналам тем, кто с ними связан. ( а ещё можно высчитывать точное время до следующего возможного события и спать ровно до него, но тогда мы не будем попадать в обновления или создания новых сущностей, либо должна быть возможность "разбудить" продьюсера, либо отправить сообщение прямо оттуда, где создаётся тем, для кого создаётся) То есть условно

someting = await database.select(SomeThing).where(SomeThing.dt.date() == datetme.today()).all()
for some in something:
     producer.send(f"{some.org}.{some.group}", body={"data": some})
# то есть фетчим из базы, решаем что делать, рассылаем кому надо

и

consumer = Consumer(topics=["someorg.team", "someorg.some_group"]) # индивидуальные подписки каждого юзера
async for msg in consumer:
    # обработать сообщение отправить в вебсокет уведомление

Но тогда вопрос, а как рассылать индивидуальные уведомления? Например, если назначена встреча или какое-то событие, условно напоминалка стоит. Создавать топик, потом стирать? Системам MQ не понравится такое обращение, думаю. Или держать постоянный топик на каждого юзера системы о_о (например, если вдруг личное сообщение пришло)... Тогда как проще?

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

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

Если пользователей сотни тысяч, но при этом событий довольно мало (сотни-тысячи в секунду в пике), то можно взять реализацию на PG/Oracle/etc из моего доклада про очереди на базе.

Решение скорее на ~тысячу пользователей на инстанс, ибо на данный момент решено пробовать self-hosted варианты. То есть всё должен держать один инстанс. Использование сервиса глобально и хостинг нами не планируется.
Сообщений в секунду - пока система в стадии планирования. Ивентов скорее мало, чем много, поэтому и вопрос про более простое решение без инфраструктурных изысков аля кафка. Но это Python, чудес скорости не будет.

Если же и пользователей миллионы и событий десятки тысяч в секунду, то готового решения из коробки я не знаю (и вроде бы такого нет) и нужно думать и смотреть на профиль нагрузки/реальные требования и т.п.
Коммерческие сервера поддержки событий через вебсокеты решают проблему через redis, но там свои проблемы.

Ну, язык значения не имеет. Но и надежность высокая не нужна, как я понимаю?
А база какая?

Postgres. Надёжность наоборот приоритет. Пропустить например напоминание о совещании - такое. У нас на ревью испытуемые жаловались, что именно поэтому не хватает системы уведомлений.

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