Thanks for replying, but it is not at all clear to me that redis was ever the right solution to the problem at hand. I'm still working out whether, in fact, Cassandra is.
Up to a fairly large scale, this particular problem needs no 'cache' at all. It needs a write-behind persistence mechanism -- a log. The simplest form of which is, of course, just a file, though that solution poses problems for backup and some failure scenarios. There are two parts to the data footprint, one growing more rapidly than the other. The faster growing part has a natural 'redis-friendly' data model (keys map to values); but it would map to EHCache as well. However, the initial redis/jredis implementation used redis, rather than local ordinary JVM objects, for the slower growing part. The lpush/ltrim usage was in here. At really gigantic scales, which I don't claim to have entirely thought through, even the slow-growing part will stop fitting into memory. However, it has a natural architecture for distribution, so there is a dilemma in my head between following the logic of the algorithm out to implement distribution, or letting something like cassandra do that for me.
