Есть, к примеру 1с. В ней есть данные, например, заявки со статусами.  И нужно как-то понимать что этот статус изменился и сразу же вытаскивать изменения.

Как это реализовать самым правильным способом?   Типа как держать постоянный коннект через Web Socket и получать изменения.

Rabbit используют для чего то подобного.

(0) http-сервис в 1С или прямой доступ к базе sql

Если не нарушая лиц.соглашение - любая шина, если пофиг - делая запросы в базу

Эээ
Шина и кролик это не онлайн - это очереди

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

(0)
1. Подписка на событие изменения статуса заявки в 1С.
2. В подписке отправляем на нужный URL HTTP запрос с json данными по статусу заявки

(6)а подписку на событие можно только вмешательством в код 1с через конфигуратор ведь?

(2)а http сервис в 1с как будет решать задачу? через подписки на события?

(4)это тоже подойдет в принципе. главное чтоб данные при изменении туда прилетали. Но ведь всеравно придется вешать подписки на события через конфигуратор 1с ?

(8) для начала реши вы хотите втягивающий или выталкивающий интерфейс?

(10)двусторонний. Дело в том, что заявки будут создаваться 1с,  поступать в веб-портал из 1с, но при этом через веб-интерфейс можно будет регулярно менять некоторые поля (корректировать) и в этом случае данные должны отпрваляться уже в 1с и там будет задействован штатный механизм версионности в рамках той конфигурации. Как вовремя отправлять туда данные мы сможем реализовать - в крайнем случае нам напишут api  Но вот как получать данные сразц после их изменения - это нужно как то события вешать и в Kafka их отправлять.

(0) При изменение 1C записывает в базу данных сервиса , где крутится веб сервер или иное ("Животное!) от даже уже web технологии что изменилось в базе данных сервиса

(1) Вообще ответ уже есть. Это же самое что в 12

(0) При возникновении события создания заявки, 1С отправляет запрос во внешний источник с новыми данными. Вот так, очень просто.

(1) Раббит используют как раз не для реального времени, а для отложенных очередей.

(15) не умеешь готовить , не говори так. Шеф Константин Ивлев@

(16) Ага, это я-то не умею. Ну ты шутник.

(16) у кролика нет гарантии доставки
только гарантия соблюдения последовательности (очереди)

(18)+ в смысле если нужна обратная связь что сообщение было получателем(ями) хотя бы принято (не говоря уже об прочитано-обработано)
надо самостоятельно обратно посылать другие сообщения например через другую очередь

Гарантии последовательности тоже нет. Он нужен только лишь для того, чтобы иметь возможность отложить обработку сообщений. Например, когда их слишком много, и в реальном времени они не успевают обработаться. Короче, это не наш случай.