и сразу же отдать ответ, сам процессинг может подождать. И тут идея, кидать запросы в очередь, например rabbit, а потом уже процессить консьюмерами. Но так как приложение под несколько клиентов( а пользователей у клиента может быть достаточно много), так же есть мысль создавать на каждого клиента очередь (т.е очередь должна создаваться динамически с приходом нового клиента).
И тут у меня затык, как динамически определять консьюмер для очереди.Какие есть варианты такое разрулить?
а зачем так делать, просто чтобы код проще писать было?
Возможно это не самое лучшее решение. Но пока нет идей как сделать обработку реквеста в бекграунде
Звучит, как будто можно очередь обычным тред пулом заменить
Там наоборот. Тредпул заменить на очередь
Достаточно много это сколько
предположительно, в среднем, нагрузка ожидается в 1к rps, в пики - больше
Налицо xy-problem.
Ну тогда можно все в памяти без доп хранилища?
Это тоже рассматривается
Ну вот, тогда с динамическим выделением проблем никаких нет
А какого рода процессинг?
Обработать вебхук от мессенджера(обработка файлов, пересылка информации во внешние системы)
А какие требования к этой системе по надёжности ?
И что за мессенджер
телега, вайбер, фб. для вайбера и фб важно быстро отдать 200 статус. если реквест потеряется - больших проблем нет, но все равно нежелательно
То есть по сути в систему вбиваются чаты в соц сетях, и она из них забирает все данные и дублирует их куда-то?
забирает часть себе данных, часть дублирует в другие системы, получает данные с других систем. все зависит от сценария Нет, чаты условно постоянные, это чатботы. т.е естественно могут добавляться для каждого клиента новые, и удаляться
Ну тогда можно вообще все проще сделать . Просто хранить собственно координаты чата(типо пары id и мессенджер) и офсет по последнее обработанное сообщение
Обсуждают сегодня