Есть вариант использовать Grizzly + Jersey для решения этой задачи. 
Скажу сразу: я имел опыт работы с Jersey, а Grizzly только "щупал" и не могу 100% утверждать что это решение подойдет. Хотя у меня есть ощущение что это то что нужно. 
Что эта связка даст:
1) Маленький, шустрый, построенный на базе NIO многопоточный http сервер, который работает в embedded режиме. 
2) Переносимые RESTful сервисы c обменом данными по http-протоколу. 
3) Звучит громоздко, но на самом деле это все очень легковесные решения.

С целью уменьшения рисков, я могу написать тестовый протопит (бесплатно конечно), по которому можно сделать некоторые суждения о пригодности технологии к данной задаче. Если тестовый прототип не понравится, то это никого ни к чему не обязывает - будете искать другое решение. В ином случае можно обсудить детали разработки рабочего приложения (время/деньги/качествофункицонал . Думаю, это наилучший подход как для вас так и для меня. 

P.S.: Что касается кэшей и прочей оптимизации, то тут нужно смотреть по факту - выявлять узкие места на рабочем сервисе. Техническая возможность для оптимизации в случае использования вышеуказанного решения имеется. (В XP программирование есть такой принцип YAGNI - You Ain't Gonna Need It - "не делай того что тебе в последствии не понадобится", а еще есть анти-паттерн "предварительная оптимизация" ;-)

Попробую пристроить свою статью в этот топик

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



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



memcached итак есть. Но он не панацея, т.к. это распределенный кеш. Его нужно дергать через сеть. Когда запросов много, то сеть также не выдерживает. Именно поэтому я хочу опрос сначала локального кеша делать, лишь потом смотреть в мемкеше и базе.



Спасибо за инфу. Запас памяти есть и я готов выделять сервера лишь под работу этого мини-сервера. Т.е. например, можно 4-8Гб выделить. Если нужно, можно и больше.

Ну, в данном случае громоздкость это примерно 3 - 4 Мб библиотек, а по разработке/отладке значительно меньше усилий нежели написание своего микро-сервера. Что касается производительности, то я и предлагаю её проверить на прототипе. От разработчика точно нет зависимости - все технологии просты, открыты и хорошо документированы. Да и с учетом планируемой вами простоты системы такая зависимость маловероятна. 



В том то и смысл, что написание очень простой логики не должно требовать написания мини-сервера с нуля... высока вероятность что это можно сделать "малой кровью". По крайней мере у меня такое ощущение. 

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

Я и имел ввиду локально. Просто, зачем программировать свой кэш для этого пункта "1. Посмотреть в у себя кеше, если такая инфа есть, то вернуть её", когда есть готовые решения. Тот же Java Caching System, или если Вы привыкли работать с memcached, то почему его не использовать не только для распределенного кэша, но и для локального (т.е. поднять локально на том же компьютере где и web сервер)?