Организация очереди для обновления данных?

мм, не совсем понял почему sphinx. Он вроде для поиска используется. У меня поиска нет вообщем-то. Реализация именно с 2мя базамиданных нужна.

sphinx не только поиск, его можно использовать для быстрого доступа к данным, у него есть так называемые realtime Index. С помощью которых не нужна переидексация, есть такой ресурс wikimart на сколько я помню они используют sphinx для подбора по параметрам.
Берем сфинкс настраиваем ему rt индексы, запускаем в режиме mysql41 и фактически получаем mysql сервер с привычными или почти привычными select/insert/update только скорость выше на порядок.
У меня так идет выборка по 3 млн товаров, данные при приходе новых позиций берутся из postgres и добавляются в бд sphinx, а выборка уже идет из последнего.

да, это было бы идеальным решением, но к сожалению общение между базами я могу осуществить только обращением к некоему API, которое мне вернет ответ в json.

Sphinx умеет возвращать json объекты. sphinxsearch.com/docs/manual-2.1.1.html#conf-sql-attr-json

ок.
Есть база, я могу получить с нее данные по пользователю сделав запрос: backendDB/getData/Вася, в ответ я получу json. Его я обработаю и запихну в базу уже для генерации картинок на основе этих данных. Далее мне нужно будет обновлять данные по Васе в своей базе, время от времени делая запрос в backendDB
Через какоето время в мою базу добавляется пользователь Петя, я делаю запрос в backendDB за данными по Пете. В дальгнейшем мне нужно обновлять данные по двум пользователям. Мне не нужно выводить данные, которые актуальны на секунду запроса, я хочу обновлять их в зависимости от количества запросов по тому или иному пользователю. Например обновлять Васю раз в 30 минут, потому что данные по нему часто запрашивают, а данные по Пете обновлять реже, например раз в 1 час, потому что его «спрашивают» редко.

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

а что мешает нужные данные сразу инсертить и в sphinx? я так делаю не лету, у меня запросы на много больше даже с меньшими объемами оперативы, смотрите у меня кассы ibm, там в опреоре 256 мб, собран сфинкс для редхата 7.2, собраны с определенныеми параметрами, у меня при обновление товара, инсерт идет в в сфинкс, именно туда. вы же можете поступить в принципе так что сделать крон с ранжированием, и организовать иерархию пользователей, добавить счетчик «популярности», так же можно закешировать и этот скрипт.

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