I think Memcached is currently better in some specific cluster scenarios, which would hopefully be researched in more depth than "Ask HN" before planning. Other

I think Memcached is currently better in some specific cluster scenarios, which would hopefully be researched in more depth than "Ask HN" before planning. Otherwise, anything you can do with Memcached, you can do with Redis, but without keys arbitrarily falling out the bottom. Also unless you're bigger than StackOverflow, most of those scenarios can be solved by "throw more RAM in it." Memcached isn't bad or anything like that. There are many algorithms where "let old stuff fall off the page" is perfectly healthy. I just don't see a need to use both, and I prefer explicitly designed expiry behavior vs. letting stuff fall out of memory, and I find Redis easier to work with. $0.02, YMMV. If your engineers are used to working with both, having both available costs way less than making them do mental gymnastics to get around not having it, although that might take itself out in onboarding time or code complexity or whatever. But mostly not, if you have good interfaces set up like Patrick. P.S. - Don't put sessions in Memcached, ever. Having users sessions die randomly because you used too much RAM is terrible design. Putting them in Redis is fine, in which case you probably want to set an expires property when they're created & update it when they're read. Or issue a rename if you're doing one-request-per-key, whichever.