Memcached versus Redis

In one line: you will be asked "Memcached or Redis?" in almost any caching discussion. The strong answer is not a feature list — it is knowing that the design in this chapter is Memcached, and being able to say exactly which requirements would push you to Redis instead.

Memcached

Introduced in 2003, Memcached is a high-performance distributed key-value store. It stores data as string-based key-value pairs, so complex objects must be serialized before storage.

It uses a shared-nothing architecture — servers operate independently without synchronization or data sharing. System logic is divided between the client and server: the client performs routing and hashing, while the server manages storage.

This disconnected design allows Memcached to achieve deterministic query speeds of O(1) and high throughput, serving millions of keys per second on high-end hardware.

Memcached scales horizontally with ease. The client process typically resides on the service host and manages interaction with the backend storage.

Common commands:

get    <key_1> <key_2> <key_3> ...
set    <key> <value> ...
delete <key> [<time>] ...

Shared-nothing is the whole design

Servers that never talk to each other cannot be inconsistent with each other, cannot gossip, cannot elect a leader, and cannot fail in coordinated ways. Everything hard is pushed to the client, which just hashes.

That is why the throughput is deterministic — there is no background coordination competing for CPU, no replication lag, no membership protocol. A Memcached server does exactly one thing.

It is the same trade load balancing framed as stateless-versus-stateful: give up coordination, get predictability. Compare the machinery key-value stores needed for the opposite choice.

Facebook and Memcached

Facebook generates user content views dynamically, which requires frequent read and write operations. Memcached was chosen for its simplicity during Facebook's early development in 2004. Over time, Facebook engineers and the Memcached community collaborated to optimize the system for large-scale deployments.

At Facebook, Memcached sits between the MySQL database and the web layer:

Check the numbers — they hold together, and they restate Lesson 6

50M in, 2.5M through: that is a 5% miss rate, exactly the 95% hit rate stated. The figures are internally consistent, which is worth confirming before you quote them.

They also make Lesson 6's availability argument concrete. If this Memcached tier disappeared, MySQL would go from 2.5M requests to 50M — a 20x increase. That is the cascading failure, with real numbers attached.

And 28 TB across 800+ servers is roughly 35 GB per server — commodity-class machines, not specialized hardware. The affordability requirement, in practice.

Redis

Redis is a data structure store used as a cache, database, and message broker. It offers richer features than Memcached but introduces additional complexity.

Redis provides built-in replication, automatic failover, and persistence, and separates the control plane (cluster management) from the data plane (data access), which improves operational reliability. However:

Because replication is asynchronous, Redis does not guarantee strong consistency.

Async replication means failover can lose writes

This is the single most important operational fact about Redis, and it follows directly from Lesson 10.

A write acknowledged by the primary has not necessarily reached the replicas. If the primary dies before it propagates and a replica is promoted, that write is gone — acknowledged to the client and then lost.

For a cache that is usually fine: the value gets recomputed from the database. It stops being fine the moment you use Redis as a database, which Redis explicitly supports. A lock, a counter, a job queue — none of those tolerate a silently dropped write.

The guarantee does not change when you change how you use it. Read the databases material's replication-lag discussion alongside this.

Redis Cluster

Redis supports high availability via Redis Sentinel and automatic partitioning via Redis Cluster. In a Redis Cluster:

• Data is automatically sharded across multiple nodes.
• Each shard consists of a primary node and secondary replicas.
• The number of shards is configurable to meet application requirements.
• A cluster manager detects failures and performs automatic failovers. The management layer includes monitoring and configuration components.

Pipelining in Redis

In the standard client-server model, the client blocks while waiting for the server's response. Sequential requests mean overall latency increases due to the wait time between each request.

Pipelining allows the client to send multiple requests without waiting for individual responses, significantly reducing the total RTT for the batch.

Pipelining reduces latency by minimizing round-trip time (RTT) and socket-level I/O, and reduces CPU overhead caused by frequent system calls. Although the server processes requests sequentially, the client can batch commands to increase throughput.

Error handling: if a client pipelines two commands and the second is invalid, the server returns a result for the first and an error for the second. The client is responsible for managing the batching logic.

Pipelining can improve throughput by a factor of five or more, even when the client and server are on the same machine (loopback address 127.0.0.1). The benefits are even more pronounced when communicating with distant machines.

5x on loopback tells you what the bottleneck really is

On 127.0.0.1 there is no network — no propagation delay, no switches, no packet loss. And pipelining still gives 5x.

That means the cost being removed is not network latency but per-request overhead: system calls, socket reads and writes, context switches. Redis operations are so cheap that the syscall around them dominates.

The general lesson, worth carrying beyond caching: when the work per request is tiny, the per-request overhead is the system. Batching wins not by making the work faster but by amortizing the ceremony around it. Same reasoning behind batch writes in the databases material.

Memcached versus Redis

Both belong to the NoSQL family, but differ in subtle ways:

On object size: Redis can store small data items efficiently. Memcached can be the right choice for file sizes above 100 K.

Feature matrix

Memcached is well suited for simpler, read-heavy workloads that benefit from multithreaded performance. Redis is suited for systems that require advanced data structures, persistence, and built-in replication.

Which one did we just design?

The answer is Memcached. The reasons:

• Client software chooses which cache server to use with a hashing algorithm.
• Server software stores the values against each key using an internal hash table.
• Least recently used (LRU) is used as the eviction policy.
• There's no communication between different cache servers.

Say this out loud in an interview

Recognizing that the system you just designed is a known open-source product is a strong close. It says the design was not invented on a whiteboard — it converged on something proven.

"What we've drawn is essentially Memcached: client-side hashing, independent servers with internal hash tables, LRU, and no server-to-server communication. If we needed persistence, richer data types, or built-in clustering, that's the case for Redis instead."

One sentence, and you have named the design, justified it, and stated its alternative.

Two questions the design answers directly

Why do third-party tools exist for persisting Memcached data? Because a lot of data is read and written to cache servers, and they may occasionally crash. After restarting, building a cache from scratch can take up to hours in specific scenarios, and that ultimately reduces system performance. So cache data may be persisted to disk to be loaded on a restart — the "cold cache" problem from Lesson 6's storage discussion.

What is the advantage of storing different data structures instead of strings only? Redis can modify data in place without wasting network bandwidth by downloading and uploading. It saves network bandwidth, time, and the effort of serializing and deserializing data. Appending one item to a 10,000-element list means sending one item, not 10,000.

Interview signal by level

Next: putting the whole thing together under interview conditions.