Engineering Insights

Every unusual thing about Redis exists because it makes a specific decision cheaper to compute.

Why single-threaded?

The obvious "why not multi-threaded?" question is the wrong one. Because command execution against the keyspace is serialized through Redis's main thread, individual data-structure operations don't need internal locking against other concurrent commands. No mutex on a hash table for two client commands racing each other. No reader-writer contention on a sorted set in the normal command path. That lets the data structure library be written more like non-concurrent C code — simpler and usually faster than making every command pay per-op synchronization overhead. That does not mean the Redis process has zero internal synchronization anywhere: background I/O, persistence, and other work can still coordinate with the main thread depending on version and configuration.

A multi-threaded Redis would need atomic reference counts on every shared object, careful lock ordering to avoid deadlocks, and thread-safe versions of every data structure — every one of which would be slower per-op. The single-threaded main loop plus process-level parallelism (run multiple Redis instances) turns out to be the higher-throughput answer.

Why in-memory only?

Because the moment you introduce disk on the read path, you lose Redis's biggest advantage: very low, predictable latency. A disk-backed cache has to handle "data is on disk, wait for it" — which means either a slow read (bad) or a background prefetch (complex). Redis's answer: fit in RAM or don't run Redis.

This also justifies dropping many general-purpose database features. No query planner. No secondary indexes. No transactions with rollback semantics. Every one of those features would either add branches to the hot path or force a complexity tax elsewhere. Redis stays simple by refusing to be a database.

Why RESP as the protocol?

HTTP + JSON is what everyone knows, so why invent RESP? Because RESP's length-prefixed framing is much cheaper to parse than an HTTP request wrapped around schema-free JSON. Redis was built during a period when text protocols dominated but the overhead was undeniable. RESP keeps the server on a small, predictable parsing path: read a type byte, read a length, then read that many bytes.

Memcached is older, simpler, and still excellent at exactly one thing. Redis is broader. The choice matters more than people think.

What Memcached does

Memcached is a flat key-value cache. Keys map to opaque byte blobs. A small command set — get/set plus add, replace, append, incr/decr, delete, touch and cas (no rich data types). Multi-threaded — worker threads handle connections in parallel and share the cache structures using synchronization. That's the entire product.

This narrowness is a feature. Memcached is tiny, unopinionated, and blindingly fast at exactly one thing — pure caching of independent byte blobs with LRU eviction.

Where they diverge

Data model. Memcached: bytes. Redis: strings, lists, hashes, sets, sorted sets, streams, HLLs, bitmaps, geo. This matters — a leaderboard on Memcached is 'read the whole list, sort in the app, write back'. On Redis it's ZINCRBY + ZRANGE.

Concurrency. Memcached is multi-threaded. Redis is single-threaded per instance but scales via I/O threads for network and by running multiple instances for parallelism. In practice, they hit similar per-machine throughput ceilings; Redis wins per-command latency because it avoids lock overhead.

Persistence. Memcached: none. If a node dies, cache is gone. Redis: optional RDB and AOF. This is huge if you use Redis as a session store or coordinator — Memcached can't play that role at all.

Replication and clustering. Memcached has consistent-hashing-based client-side sharding, but no built-in replication. Redis has both. Different failure models.

When each wins

Choose Memcached if: you want a pure blob cache, you don't care about persistence, and you value operational simplicity. Memcached is the platonic ideal of "one job, done well".

Choose Redis if: you need any data structure beyond string, any operation beyond get/set, persistence, replication, pub/sub, streams, or coordination primitives. Redis is what you reach for when you realize the cache is going to grow features.

"Can Redis replace my database?" is one of the most common questions. The honest answer requires understanding both what Redis can do and what it deliberately can't.

What a database gives you

A relational database is optimized for arbitrary queries over persistent, disk-resident data. Joins across tables, aggregations, indexes on multiple columns, ACID transactions with rollback, foreign keys, schema evolution, dataset sizes measured in TB. All of that is expensive per-operation but essential for a system of record.

What Redis gives you instead

Fast key-based lookups on rich structures. You know the key. You know the shape (a string, a hash, a sorted set). You want the answer in microseconds. Redis is exactly right for that access pattern and exactly wrong for anything else.

You can't SELECT * FROM users WHERE age > 30 AND country = 'FR' on Redis. There's no query engine. You'd have to design your Redis keys such that answering that question is a direct lookup — e.g., a sorted set per country by age. That works but requires modeling the queries you'll run up front.

When Redis is the right primary store

Redis is a legitimate primary store — not just a cache — for data that has specific properties: small enough to fit in RAM, accessed by key, doesn't require ad-hoc queries, and where you're OK with the async-replication durability model (or can pay for synchronous replication).

Examples: leaderboards, real-time counters, feature-flag configurations, session state, active user presence, pub/sub coordination. All of these are Redis-native. Putting them in Postgres works, but it means paying for a much heavier query and storage path for an access pattern Redis handles directly.

When Redis is the wrong primary store

Anything you need to query flexibly. Anything larger than RAM. Anything that needs strict cross-object transactions with rollback. Anything where losing the last second of writes on a crash is unacceptable and you can't afford dedicated synchronous replication infrastructure.

The mistakes you'll only hear about after the incident. These are among the most common.

Treating Redis as a full-featured database

Storing JSON blobs and expecting to query them. Doing KEYS user:* to "find all users". Building an ORM on top of SET/GET. Redis is optimized for known-key, known-shape access. If you're doing anything else, either use a real database for that part of your data, or remodel the keys so the questions you actually ask become direct lookups.

Missing TTLs on cache keys

Every cache entry should have EXPIRE. Otherwise stale data lingers forever, memory grows unbounded, and you'll ship bugs where users see data that was invalidated hours ago. The right question when you SET a cache key: "what's the TTL?" — no answer means think again.

No monitoring on memory

Redis eviction is silent by default. If you cross maxmemory and don't watch evicted_keys, you'll notice only when users complain about missing sessions or lost cart data. Track memory headroom against maxmemory for your workload, and alert on any nonzero evicted_keys when the eviction policy isn't "pure cache".

Big keys

A single Redis key with 10 million list items or a 100 MB string is a landmine. LRANGE 0 -1 on it stalls the server. Deletion (DEL) blocks for the time it takes to free every item. The problem is impact, not one magic size: a key is "big" when reading, serializing, transferring, deleting, replicating, persisting, or migrating it becomes expensive. If one key no longer moves cheaply, shard by hash-tagged sub-keys.

Sharing one Redis for cache and coordination

When cache hits maxmemory and starts evicting, your maxmemory-policy allkeys-lru will happily evict distributed locks and rate-limit counters too. Now two workers hold the same lock and process the same payment twice. Fix: separate instances with separate policies — or give the instance that holds locks and counters noeviction. Locks should still carry a TTL (plus a fencing token) so a crashed holder cannot block everyone forever.

Using MULTI as if it's ACID

Redis MULTI/EXEC gives atomicity in the "executed as one uninterruptible unit" sense. It doesn't roll back on errors. If command 3 of a 5-command transaction fails, commands 4 and 5 still run. If you want conditional logic based on values ("read X, then write X+1 only if X hasn't changed"), use WATCH or Lua scripts.

The questions engineers keep asking. Short, honest answers.

How public engineering writing has described Redis in real systems. Treat these as illustrative patterns, not claims about any company's exact current 2026 architecture.