ну по сути да. там в разные стороны можно распределить.
например Клиент-кафка-сервер

либо сервер1-кафка-сервер2

реббит примерно по тому же принципу работает

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

В принципе, если я правильно понимаю, то настроив кафку так: сервер -> кафка -> подписчик, мы просто переложим обязанность разослать уведомление о наличии обновления на кафку, так?

все верно, она для этого и нужна

теперь я понял, спасибо. Это не самая простая реализация, хотя все зависит от поставленной задачи

поэтому я и написал. тут не все так просто, как показалось со стороны.

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

Ну так может и нам не стоит
Я просто прикинул что надо делать ещё интерфейс и ещё минимум наследников для каждой модели, а лучше опять же интерфейсы и налл-объект реализации
И это как-то только чтоб налл не возвращать из базы
Выглядит оверхедм
Но может я не понимаю

Есть класс и его методы, правильно ли сделать так, что одному экземпляру будут обращаться из нескольких потоков?

или лучше для каждого создать свой?

только позавчера этот вопрос поднимали. Я еще показывал код. Делаешь 1 экземпляр, к нему обращаются 100500 потоков и локируй потоки,

Нее, я не об этом

там другая ситуация

А почему нет?

Только лочить доступ

с точки зрения архитектуры это ужас и этого делать нельзя. Проблем может быть много. Вот цитата из Фаулер "Архитектура корпоративных программных приложений":

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

Аналогично и с потоками будет замедление вызовов. Плюс как сказали выше тогда нужно блокировать объект, а это убивает концепцию асинхронности, так как пока 1 поток будет работать с объектом, другой будет ждать. Плюс если 1 поток сломает объект, корректно работать не смогут и остальные. Так что лучше для каждого потока создавать свой экземпляр. А вообще рекомендую прочесть Фаулер "Архитектура корпоративных программных приложений" 5ю главу про управление параллельными заданиями.Так что принимай решение сам, но это отнюдь не хорошая идея

2 потока обратятся к 1му объекту.... и получишь ты exception или еще чего лучше Undefined behavior

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