Redis vs Memcached: a cache, or a toolbox?

Memcached is a deliberately minimal, multithreaded key-value cache: strings in, strings out, evicted under memory pressure, no persistence, no bells. That simplicity makes it lean and easy to scale for one job — caching. Redis is a data-structure server: alongside strings it offers lists, sets, sorted sets, hashes, streams, bitmaps and more, plus persistence, replication, pub/sub, transactions, Lua scripting and clustering. It caches too — but it does far more.

Memcached is multithreaded at the core: multiple worker threads share one big hash table behind a lock, so on a 32-core box it can genuinely use many cores for raw get/set throughput. Redis's core command execution is single-threaded — one thread runs your GET, LPUSH or ZADD at a time, which is precisely what makes every Redis command atomic with no locking, no race conditions, no partial writes visible to another client. Redis 6+ added I/O threads to parallelize the cheap work of reading bytes off the socket and parsing the protocol, but command execution itself stays single-threaded.

In practice this rarely matters. A single Redis core can push hundreds of thousands of simple operations per second — memory bandwidth and network I/O become the bottleneck long before the single-threaded execution model does. Memcached's multithreading only shows a real edge at extreme concurrency on very large multi-core machines doing nothing but plain key-value gets — exactly the narrow case where Memcached's minimalism was designed to win. For anything with mixed operation types, larger values, or data structures, Redis's single-threaded simplicity is a feature: no lock contention, no torn writes, and command behavior you can reason about without thinking about interleaving.

Say you need a live leaderboard for 2 million players, updated on every game and read constantly for "top 100" and "my rank." With Memcached, there's no native ranked structure — you'd fetch the entire score set into your application, sort it in-memory, and re-cache the sorted result, or maintain your own auxiliary ranking system in a real database and use Memcached only to cache the rendered page. Either way, a single score change means recomputing or invalidating a chunk of that cached structure, and "what's my rank right now" is expensive to answer freshly.

With Redis, a leaderboard is a ZADD leaderboard <score> <player> away from existing as a first-class sorted set. ZRANGE leaderboard 0 99 REV returns the top 100 in O(log N + 100) time. ZRANK leaderboard player123 returns any player's live rank in O(log N). No batch recomputation, no cache invalidation dance — the data structure is the answer, kept correct automatically as scores update. This is the concrete shape of "Redis is a data-structure server": the leaderboard isn't a caching problem bolted onto a database, it's a native operation.