Так все таки? БД или JMS/MQ ?

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

Насколько я понимаю эта линка - конфигурация всех подписок на sql.ru?

https://www.sql.ru/forum/actualrss.aspx?id=11

Верно?

Полностью согласен насчет масштабирования. Эта точка приложения сил - самая легкая и алгоритмически
простая. Если масштабирование Real-Application-Cluster например для Оракла имеет объективные ограничения
(там выше 100 узлов уже может начинаться шторм служебного трафика) то для таких слабо-связных
систем или eventually связных - это число отодвинуто очень далеко.

Кроме того брокеры и продюсеры и консюмеры мы можем разделять спокойно до тех пор пока бизнес-логика
позволяет. Разделить DBMS на части - это тот еще челледж. Особенно чтобы ПОСЛЕ разделения БД сохраняла
те-же свойства что и до разделения.

Для соединения точка-точка это вполне себе работает. 1 месседж == 1 файл.
Только нужно гарантировать чтобы только 1 процесс брокера
считывал файлы. Иначе есть риск прочитать файл дважды.

Ордеринг (FIFO) мы гарантировали через хронологические названия файлов. Например шаблон
yyyy-mm-dd-hh-mm-ss-ms.xml в файловой системе NTFS5 всегда сохранялся в директории
с сортированном порядке (это свойство NTFS) и извлекая файлы листингом директории
мы получали коробочную сортировку без усилий.

Мы строили такую систему в 2003 году. На базе Microsoft.Net.

Бродкаста (подписок на топики) у нас не было. Просто было специфичное ТЗ.

Да не в монолите дело. И хотя я чаще голосую за монолит. Просто сама жизнь и сами
условия ведения бизнеса диктуют если не разделение задачи на части - то просто
интеграцию. Ты делаешь спокойно монолит. Потом к тебе приходит бизнес и говорит
- вот нам тут надо черпать тикеры и прайсы из такой-то и такой-то системы.
И ничего тут не поделаешь.

И что твоё приложение после этого? Монолит? Не?

Ну тут два варианта:
1. Наши события - эт не события, а просто сущности в БД отсортированные по дате модификации. Но тогда сущность может "прыгать" по фиду. Сначала она была в мартовском фиде, теперь в августовском. Это не требует доп таблиц.
2. Ну или заводим доп таблицу с событиями и записываем их в БД. Это в любом случае нередко удобно для аудитов и дебагинга.

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

По поводу прыгающих сущностей и доп таблиц. Я голосую против. Потому-что Consumer должен быть простым.
Тоесть если я и Петро к примеру подписались на новости изменения цен на акции Luxoft или Yandex, то
мы не хотим парсить никаких фидов и вообще мы ничего не хотим делать на клиене.

Мы просто делаем цикл или хендлер наподобие того что я приводил из учебных примеров и имеем
новости по ценам на акции.




Кстати подписка - важный момент. Если я уже прочитал новость а Петро еще не прочитал - то брокер
будет хранить ее хоть 1000 лет (на самом деле согласно политике retention которая описана в брокере)
и Петро получит свои новости по акциям когда поднимет свой упавший Consumer.

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

Кстати Kafka в организации хранения сообщений очень экономна. Ей достаточно хранить только offset прочитанного
для каждого потребителя. Группа соотв - должна хранить группу оффсетов.

И как впечатления от GraphQL?

Мне показалось что слишком сложно для большинства простых потребителей контента.

GraphQL в смысле КОНТЕНТА предлагает офигенскую фичу. Вы получаете на response
трафик который содержит только те поля и суб-документы которые зареквестили.

Но чтобы эту фичу полноценно реализовать - нужна либо какая-то очень гибка DBMS
наподобие графовой. Либо нужен чудовищно-сложный SQL-билдер запросов
который может вытянуть вообще всю твою базу в зависимости от того что
юзер запросил в реквесте.

Если вы искусственно ограничите этот билдер и скажете что - нахрена дескыть
тянуть дочерние суб-таблицы. Пускай сделают 2-мя GrapQL реквестами.

То возникает вопрос. А нахрена вы вообще брали GraphQL?

У вас - REST-style сборки модели ответа!

Вернитесь обратно в REST!

По теме топика, Станислав, ваше предложение - самое интересное.

Но я честно говоря не совсем понимаю какого рода сервис вы предоставляете?
Возможно сервис фидов это не совсем MQ. Это скорее ... SNAPSHOT сервис
где нам предлагается самим собрать последние новости.

Верно ли я понял? И можете привести пример такого ответа от вашего фид-сервиса.
Ну например я захотел фид по ценам на акции it-компаний.

Я не знаком с gRPC и не использовал его. Но фичей преподносится некий гугловый вариант
компактной сериализации данных. Эту сериализацию вообще интересно рассматривать
только в сравнении со смежными технологиями такими как

- Apache AVRO
- Apache Thrift

В моём понимании они делают тоже самое. Это как ... сравнивать 5 видов json форматов.
Вроде они разные. Но внутри всё тоже самое.

JMS/MQ система не обязательно должна поставлять полный документ. Если отдел А уведомляет отдел Б
о том что результат уже готов - он может прислать мессендж с линком на хранилище где уже лежит
отчот. Это решает многие вопросы нагрузок.

Нет такого требования. Низкий latency как раз важен для классических REST/SOAP систем.
Для JMS/MQ это требование как раз может быть смягчено за счет других бизнес требований
и конфигурации. Те-же гарантии доставки например и транзакции.