Привет, все через хуки. Сейчас бот на php и по этому обрабатываю сразу, но переписываю его на яву, там будет очередь в памяти. Если что то интересно можешь без проблем в личку писать, я в течении дня всегда отвечу

У меня даже на php обработка запроса и работа с tg api развязана через очередь.

мы в одном из проектов используем rabbitmq для очереди

По этому телегу достаточно быстро отпускаю

Сейчас тренд kafka, у rmq ведь есть косяк, если получателей несколько и один не отвечает, то вся очередь встанет ?

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

Т.е если потом этот получатель проснется, то он старые сообщения уже не получит ?

Емнип, нет. Очередь пойдет дальше с того момента, как проснется

Ещё раз, есть 2 получателя, в какой то момент один из них перестал работать, что то в нём сломалось, как с ним поступит rmq ? Ты говоришь что просто будет слать второму, я и спрашиваю, получается когда первый проснется, события, которые он проспал, он уже не получит ?

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

А, стоп. Мы говорим о разном. Я о конфигурации, когда сообщение доходит до одного из подписчиков, а не до всех

Когда мы используем rmq как балансировщик

Пардон а зачем их в бд держать?
У меня модер к примеру на хуках, получает апдейт, делает то что можно без обработки сразу, а сложное в фоновом потоке. Плюс в фоновом потоке отсылается всякие приветствия и тп. Часть отдается сразу в вебхуке, часть в очереди и часть шлется запросом

По факту задача хука только принять данные и сказать телеге "все ок" а обработку в фон послать

Чтоб работало быстро

У меня вообще приемом сообщений занимается отдельный демон, который скидывает все сообщения в очередь