Hello papaf. If you try to do the math of the number of messages you can hold using four 64 GB Linux boxes you'll find that it's a perfectly viable (and very scalable) solution to use Redis in a number of real-world scenarios.

Note that with this setup you don't need N additional memcached servers, so all the $ can be spent in RAM for the DBs.

Im my personal experience with high traffic web services what I discovered is that anyway when the on-disk dataset starts to get bigger than the available RAM performances are horrible anyway. Also note that when there is a lot of data to Index, the right thing to do can be the following:

take all the metadata on Redis, for fast access. Take the "bulk" data on MySQL, just an incremental ID + Blob field. Perform queries against both.

It is absolutely possible to add some kind of aging algorithm to swap not recently used keys on disk to Redis in order to allow for bigger than RAM datasets, but most people dealing with high traffic sites told me "don't do it, it's useless because we have access patterns that are more or less evenly distributed among the key space".