Redis & Caching Vocabulary: 25 Terms Every Backend Developer Needs
Learn Redis and caching vocabulary — cache hit/miss, TTL, eviction policies, Redis data structures, pub/sub, clustering, and caching patterns explained for backend developers.
Caching is one of the most effective performance tools available to backend developers, and Redis is the most widely used caching technology in production systems. Whether you are reviewing a caching strategy, debugging a cache-related incident, or designing a new feature, this vocabulary will help you communicate clearly and confidently.
Caching Fundamentals
Cache Hit and Cache Miss
A cache hit occurs when the requested data is found in the cache. A cache miss occurs when it is not — the system must fetch the data from the slower primary source (usually a database).
“Our cache hit rate is 92% — only 8% of requests are going to the database."
"After the deployment, the cache was cold and the hit rate dropped to zero. The database couldn’t handle the full load.”
Cache Warming
Cache warming (also called priming the cache) is the process of proactively loading data into the cache before it is needed — typically after a deployment or restart — so the system doesn’t suffer a thundering herd of cache misses.
“We warm the cache on startup by pre-loading the most frequently accessed product pages.”
Cache Stampede
A cache stampede (also called a thundering herd) happens when many requests simultaneously miss the cache for the same key and all rush to regenerate it at once, overwhelming the database. It typically occurs when a popular cached item expires.
“The cache key for the homepage expired at the exact moment we had a traffic spike — classic cache stampede. We fixed it with probabilistic early expiration.”
TTL (Time to Live)
TTL is the time period after which a cached item expires and is removed from the cache. Choosing the right TTL balances freshness (short TTL) against performance and database load (long TTL).
“Set a TTL of 5 minutes for the user profile — it doesn’t need to be real-time, and it’ll significantly reduce database queries."
"The TTL is too short — it’s expiring before most users make a second request, so we’re barely benefiting from the cache.”
Eviction Policy
An eviction policy determines which items Redis removes when memory is full. Common policies:
- LRU (Least Recently Used) — removes the item that hasn’t been accessed for the longest time.
- LFU (Least Frequently Used) — removes the item accessed least often over time.
- volatile-lru — applies LRU only to keys that have a TTL set; never evicts keys without TTL.
- allkeys-lru — applies LRU to all keys.
- noeviction — returns an error instead of evicting. Use only when you want to prevent data loss.
“Set the eviction policy to
allkeys-lruso Redis can free memory automatically under pressure."
"We hit a RedisOOMerror — the eviction policy wasnoeviction. Switch toallkeys-lru.”
Redis Data Structures
String
The string is the simplest Redis data type — a key mapped to a binary-safe value. Strings can hold text, numbers, or serialised JSON. Maximum size: 512 MB.
“Store the serialised user session as a Redis string with a 30-minute TTL.”
Hash
A hash stores a map of field-value pairs under a single key — similar to a dictionary or object. Efficient for representing objects where you might want to update individual fields.
“Store the user’s profile as a Redis hash so we can update the
lastLoginfield without rewriting the entire object.”
List
A list is an ordered collection of strings. You can push and pop from either end (LPUSH/RPUSH, LPOP/RPOP), making it useful for queues and stacks.
“We use a Redis list as a simple work queue — workers pop tasks from the left.”
Set
A set is an unordered collection of unique strings. Useful for membership checks, tags, or tracking unique visitors.
“Store the set of features enabled for each user in a Redis set — checking membership is O(1).”
Sorted Set (ZSet)
A sorted set maps unique members to floating-point scores and keeps them sorted by score. Perfect for leaderboards, rate limiting, and time-series data.
“We use a sorted set for the leaderboard — the score is the user’s point total, and Redis keeps them sorted automatically.”
Stream
A stream is an append-only log of messages, similar to Kafka. Consumers can read messages in order and track their position with a consumer group.
“We switched from a Redis list queue to a stream so multiple consumer groups can process the same events independently.”
Pub/Sub
Pub/Sub
Pub/Sub (publish/subscribe) lets publishers send messages to named channels, and subscribers receive them in real time. Redis Pub/Sub is fire-and-forget — messages are not persisted.
“We use Redis Pub/Sub to push real-time notifications to connected WebSocket clients."
"Remember that Pub/Sub messages are lost if no subscriber is listening at the moment of publish — use streams if you need durability.”
Lua Scripting
Lua scripts run atomically on the Redis server. They are useful for complex operations that need to read and write multiple keys without the risk of another client modifying data in between.
“We use a Lua script to atomically check a rate limit counter and increment it — no race condition.”
Reliability and Scale
Redis Cluster
Redis Cluster is the built-in sharding solution. Data is automatically distributed across multiple nodes using hash slots. It provides both horizontal scalability and high availability.
“We moved to Redis Cluster because a single node can’t hold all our data in memory.”
Redis Sentinel
Redis Sentinel provides high availability for a single Redis instance (not cluster). Sentinels monitor the primary node and automatically promote a replica if the primary fails.
“We use Sentinel with one primary and two replicas — Sentinel handles automatic failover within seconds.”
Persistence: RDB and AOF
Redis offers two persistence mechanisms:
- RDB (Redis Database) — creates periodic point-in-time snapshots. Fast to restore, but may lose data since the last snapshot.
- AOF (Append-Only File) — logs every write command. More durable, but larger files and slower recovery.
“We use AOF persistence — we can afford the extra disk I/O, but we can’t afford to lose more than a second of data.”
Caching Patterns
Cache-Aside (Lazy Loading)
In the cache-aside pattern, the application checks the cache first. On a miss, it fetches from the database and writes the result to the cache. The cache only contains data that has actually been requested.
“We use cache-aside for product data — we only cache what users actually look at.”
Write-Through
In write-through, every write goes to both the cache and the database simultaneously. The cache is always consistent with the database.
“Write-through ensures the cache is never stale, but it adds latency to every write.”
Write-Behind (Write-Back)
In write-behind, writes go to the cache first and are asynchronously flushed to the database. This reduces write latency but risks data loss if the cache fails before the data is persisted.
“Write-behind gives us low write latency, but we need to ensure the queue is durable so we don’t lose writes.”
Distributed Lock
A distributed lock (often implemented with Redis SET NX EX) prevents multiple processes from executing a critical section simultaneously across different servers.
“We use a Redis distributed lock to ensure only one instance of the job runs at a time, even when we have multiple workers.”
How to Use This in Conversation
In architecture review:
“Should we use cache-aside or write-through here? Write-through guarantees consistency but adds latency to every write.”
In incident response:
“The database is hammered. Check the Redis cache hit rate — if it’s dropped, we might have a cache stampede from an expired key.”
In code review:
“This key has no TTL — it’ll never expire and will grow indefinitely. Set an appropriate TTL.”
In planning:
“The leaderboard requires sorted results. Use a Redis sorted set — that’s exactly what it’s designed for, and it’ll be far faster than a SQL
ORDER BYwith a million rows.”
Redis vocabulary is essential for any backend developer working on performance, real-time features, or distributed systems. Understanding these terms will help you design better caching strategies and participate confidently in system design discussions.