Redis internals: why it is fast and how to use it safely

Redis is an in-memory data store. It keeps data in RAM, so reads and writes take microseconds. It is used for caches, sessions, counters, queues, leaderboards and rate limiters. This site uses it for page-view counts.

Why it is fast

• Data lives in memory, not on disk.
• Commands run on one main thread, so there are no locks between commands and each command is atomic. (Newer versions can use extra threads for network I/O, but commands still run one at a time.)
• Simple, well-chosen data structures implemented in C.

Data structures

Type	Typical use
String	cache value, counter (INCR)
Hash	an object with fields, like a user
List	simple queue, recent items
Set	unique items, tags
Sorted set	leaderboards, rate limiting by time
Stream	append-only event log

Persistence

Memory is lost on restart, so Redis can save to disk:

• RDB snapshots: a point-in-time file every so often. Compact and fast to load, but you can lose the last few minutes.
• AOF (append-only file): logs each write. Safer (lose at most about a second with the right setting), but bigger.
• Many setups use both. A pure cache can turn persistence off.

Memory limits and eviction

RAM is finite. Set maxmemory and choose a policy such as allkeys-lru for a cache. Without it Redis can use all memory and get killed.

Scaling

• Replication: one primary, several replicas for reads and failover.
• Redis Cluster: the keyspace is split into 16,384 hash slots spread across nodes, so data and load scale out.

Things to watch

• One slow command (like KEYS * on a big database) blocks everyone. Use SCAN.
• Very large keys hurt latency.
• Do not expose Redis to the internet. Bind it to localhost or a private network and set a password.

Takeaway: Redis is fast because it is simple, in-memory and single-threaded for commands. Choose the right structure, set a memory limit, and keep it private.

---

System Design series, Part 2 (building blocks): topic 1 of 14.