Why caching patterns matter in Redis - Why It Works This Way

Overview - Why caching patterns matter

What is it?

Caching patterns are ways to store data temporarily so it can be accessed faster later. They help reduce the time it takes to get information by keeping a copy close to where it is needed. Redis is a popular tool used to manage these caches because it is very fast and easy to use. Understanding caching patterns helps you decide what data to save and when to update or remove it.

Why it matters

Without caching patterns, every request for data would have to go to the main database or source, which can be slow and costly. This can make websites or apps feel sluggish and frustrate users. Caching patterns solve this by making data retrieval quick and efficient, improving user experience and saving resources. They also help systems handle more users at the same time without slowing down.

Where it fits

Before learning caching patterns, you should understand basic data storage and how databases work. After mastering caching patterns, you can explore advanced topics like cache invalidation, distributed caching, and performance tuning in Redis and other systems.

Mental Model

Core Idea

Caching patterns organize temporary data storage to speed up access and reduce load on main data sources.

Think of it like...

Imagine a kitchen where you keep frequently used spices on the counter instead of in a distant cupboard. This way, cooking is faster because you don’t have to walk far to get what you need.

┌───────────────┐       ┌───────────────┐       ┌───────────────┐
│ Client Request│──────▶│   Cache (Redis)│──────▶│ Main Database │
└───────────────┘       └───────────────┘       └───────────────┘
       │                      │                      │
       │<-----Fast Response----│                      │
       │                      │<----Slower Response---│

Build-Up - 6 Steps

1

Foundation

What is caching and why use it

Concept: Caching stores copies of data temporarily to speed up future access.

When you ask for data, instead of always going to the main database, caching keeps a copy nearby. This means the system can answer faster because it doesn’t have to do the full work again. Redis is a tool that helps store these copies in memory, which is very fast.

Result

Data requests are answered more quickly, reducing wait times.

Understanding caching is key to improving system speed and user experience.

2

Foundation

How Redis stores cache data

Concept: Redis keeps data in memory for very fast access and supports different data types.

Redis stores data in RAM, which is much faster than disk storage. It can hold simple values like strings or more complex types like lists and sets. This flexibility lets you cache many kinds of data efficiently.

Result

Cached data is retrieved in milliseconds or less.

Knowing Redis’s memory-based storage explains why it’s so fast for caching.

3

Intermediate

Common caching patterns explained

🤔Before reading on: do you think caching always stores all data or only some? Commit to your answer.

Concept: Different patterns decide what data to cache and when to update or remove it.

Some common caching patterns are: - Cache Aside: The app checks cache first, then database if needed, and updates cache. - Read Through: Cache automatically loads data when missing. - Write Through: Data is written to cache and database at the same time. - Write Back: Data is written to cache first and later saved to database. Each pattern fits different needs and tradeoffs.

Result

You can choose the best pattern to balance speed, freshness, and complexity.

Recognizing patterns helps design caching that fits your app’s behavior and data needs.

4

Intermediate

Why cache invalidation is tricky

🤔Before reading on: do you think cached data always stays correct forever? Commit to yes or no.

Concept: Cache invalidation means removing or updating cached data when it changes in the main source.

If cached data becomes outdated, users get wrong information. Invalidation can be done by setting expiration times or updating cache when data changes. But deciding when and how to invalidate cache is hard and can cause bugs or slowdowns if done poorly.

Result

Proper invalidation keeps cache fresh and reliable.

Understanding invalidation challenges prevents common bugs and stale data problems.

5

Advanced

Balancing cache size and performance

🤔Before reading on: do you think bigger cache always means better performance? Commit to yes or no.

Concept: Cache size affects speed and memory use; too big or too small can cause issues.

A cache that is too small will miss data often, causing slow database calls. A cache that is too big uses too much memory and can slow down Redis. Eviction policies like LRU (Least Recently Used) help remove old data to keep cache efficient.

Result

Balanced cache size improves speed without wasting resources.

Knowing how cache size impacts performance helps optimize system resources.

6

Expert

Surprising effects of cache stampede

🤔Before reading on: do you think many requests for missing cache data happen smoothly or cause problems? Commit to your answer.

Concept: Cache stampede happens when many requests ask for the same missing data, causing overload.

If cache expires and many users request the same data at once, all requests hit the database, causing spikes and slowdowns. Techniques like request coalescing or locking prevent this by letting only one request refresh the cache while others wait.

Result

Systems stay stable and fast even under heavy load.

Understanding cache stampede helps design resilient caching for real-world traffic spikes.

Under the Hood

Redis stores cached data in memory using efficient data structures. When a request comes, Redis checks if the data exists in its fast-access memory. If yes, it returns immediately. If no, the application fetches from the database and updates Redis. Redis uses expiration times and eviction policies to manage memory and keep data fresh. Internally, Redis handles commands atomically to avoid race conditions.

Why designed this way?

Redis was designed for speed and simplicity, using in-memory storage to avoid slow disk access. Its single-threaded event loop model avoids complex locking, making operations fast and predictable. The design balances speed, simplicity, and flexibility, supporting many caching patterns and data types.

┌───────────────┐
│ Client Request│
└──────┬────────┘
       │
       ▼
┌───────────────┐
│   Redis Cache │
│  (In-Memory)  │
└──────┬────────┘
       │ Cache Hit?
   Yes │       No
       ▼         ▼
┌───────────┐  ┌───────────────┐
│ Return    │  │ Query Database │
│ Cached    │  └──────┬────────┘
│ Data      │         │
└───────────┘         ▼
                  ┌───────────────┐
                  │ Update Redis  │
                  │ Cache         │
                  └───────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does caching always guarantee the freshest data? Commit to yes or no.

Common Belief: Caching always gives the most up-to-date data because it stores copies.

Reality: Cached data can be outdated if not properly invalidated or refreshed.

Why it matters: Relying on stale cache can cause wrong information shown to users or incorrect decisions.

Quick: Is bigger cache always better for performance? Commit to yes or no.

Common Belief: The larger the cache, the faster the system will be.

Reality: Too large caches can waste memory and slow down eviction, hurting performance.

Why it matters: Oversized caches can cause system slowdowns and increased costs.

Quick: Does caching reduce database load in all cases? Commit to yes or no.

Common Belief: Caching always reduces the load on the main database.

Reality: Poor caching patterns or cache stampedes can cause spikes in database load.

Why it matters: Unexpected database overloads can crash systems and degrade user experience.

Quick: Can you cache everything without limits? Commit to yes or no.

Common Belief: You can cache all data without worrying about memory or complexity.

Reality: Caching everything is impractical due to memory limits and complexity of invalidation.

Why it matters: Trying to cache all data leads to wasted resources and harder maintenance.

Expert Zone

1

Cache expiration times should balance data freshness and system load to avoid frequent reloads or stale data.

2

Eviction policies like LRU or LFU impact which data stays in cache and can affect hit rates significantly.

3

Distributed caching introduces challenges like consistency and synchronization that require special patterns.

When NOT to use

Caching is not suitable for data that changes every millisecond or requires strict consistency. In such cases, direct database queries or specialized real-time data stores are better. Also, caching is less useful for small-scale apps where database load is low.

Production Patterns

In production, cache aside is common for flexibility, while write-through is used when data consistency is critical. Techniques like cache warming, lazy loading, and request coalescing help optimize performance. Monitoring cache hit rates and adjusting TTLs are standard practices.

Connections

Memory Hierarchy in Computer Architecture

Caching patterns in Redis mirror how CPUs use cache memory to speed up access to main memory.

Understanding CPU cache helps grasp why caching data closer to the user speeds up systems and how cache misses slow things down.

Supply Chain Inventory Management

Caching is like keeping inventory close to customers to reduce delivery time, similar to warehouses near cities.

Knowing supply chain logistics clarifies why caching reduces delays and how overstocking or understocking cache affects performance.

Human Short-Term Memory

Caching resembles how the brain keeps recent information handy to avoid recalling from long-term memory every time.

This connection shows why temporary storage speeds up tasks and why forgetting (cache eviction) is necessary to avoid overload.

Common Pitfalls

#1 Not setting expiration on cached data causes stale information.

Wrong approach:

SET user:123 "John Doe"

Correct approach:

SETEX user:123 3600 "John Doe"

Root cause:

Learners forget to add expiration, so cache never refreshes and serves outdated data.

#2 Updating database without updating cache leads to inconsistent data.

Wrong approach:

UPDATE users SET name='Jane' WHERE id=123; -- no cache update

Correct approach:

UPDATE users SET name='Jane' WHERE id=123; DEL user:123

Root cause:

Learners miss cache invalidation step after database changes, causing stale cache.

#3 Caching too much data exhausts memory and slows Redis.

Wrong approach:

Cache entire large dataset without limits.

Correct approach:

Cache only frequently accessed data with proper eviction policies.

Root cause:

Misunderstanding cache size limits and eviction leads to resource exhaustion.

Key Takeaways

Caching patterns help store data temporarily to speed up access and reduce load on main databases.

Choosing the right caching pattern balances speed, data freshness, and system complexity.

Proper cache invalidation is critical to avoid serving outdated information.

Cache size and eviction policies must be managed carefully to maintain performance.

Understanding caching deeply helps build fast, reliable, and scalable applications.

Practice

1. Why is caching important in Redis when building applications?

easy

A. It slows down the application by adding extra steps

B. It permanently saves all data without expiration

C. It deletes all data immediately after storing

D. It stores data temporarily to make data retrieval faster

Solution

1. Step 1: Understand caching purpose

   Caching temporarily stores data to reduce the time needed to get it again.

2. Step 2: Identify correct caching behavior in Redis

   Redis caching speeds up apps by storing data for quick access, not permanent saving or immediate deletion.

3. Final Answer:

   It stores data temporarily to make data retrieval faster -> Option D

4. Quick Check:

   Caching = Temporary fast storage [OK]

Hint: Caching means temporary storage for speed, not permanent save [OK]

Common Mistakes:

• Thinking caching saves data permanently
• Believing caching slows down the app
• Confusing caching with immediate data deletion

2. Which Redis command correctly sets a key with an expiration time of 60 seconds?

easy

A. GET key EX 60

B. SET key value EX 60

C. DEL key 60

D. EXPIRE key SET 60

Solution

1. Step 1: Recall Redis syntax for setting key with expiration

   The correct command is SET with EX option to set expiration in seconds.

2. Step 2: Check each option's correctness

   SET key value EX 60 uses SET key value EX 60 which is valid. Others misuse commands or order.

3. Final Answer:

   SET key value EX 60 -> Option B

4. Quick Check:

   SET with EX sets key and expiration [OK]

Hint: Use SET with EX to set expiration in seconds [OK]

Common Mistakes:

• Using GET instead of SET to set values
• Misplacing EXPIRE and SET commands
• Trying to delete keys with expiration time

3. Given this Redis command sequence:
SET user:1 "Alice" EX 10
GET user:1
What will the GET command return if run 15 seconds after the SET?

medium

A. nil

B. Empty string

C. Error: key expired

D. "Alice"

Solution

1. Step 1: Understand expiration effect

   SET with EX 10 means key expires after 10 seconds, so after 15 seconds key is gone.

2. Step 2: Predict GET result after expiration

   GET on expired key returns nil (no value), not error or empty string.

3. Final Answer:

   nil -> Option A

4. Quick Check:

   Expired key returns nil on GET [OK]

Hint: GET returns nil if key expired before access [OK]

Common Mistakes:

• Expecting old value after expiration
• Thinking GET returns error on expired keys
• Confusing empty string with nil

4. You wrote this Redis code:
SET session:123 "active"
EXPIRE session:123 0
What is the problem with this code?

medium

A. EXPIRE command syntax is incorrect

B. Key will never expire because 0 means infinite

C. Expiration time 0 deletes the key immediately

D. SET command must include expiration time

Solution

1. Step 1: Understand EXPIRE with 0 seconds

   EXPIRE with 0 seconds deletes the key immediately.

2. Step 2: Identify the effect on the key

   After EXPIRE session:123 0, the key is deleted immediately, which may be unintended.

3. Final Answer:

   Expiration time 0 deletes the key immediately -> Option C

4. Quick Check:

   EXPIRE 0 deletes key immediately [OK]

Hint: EXPIRE 0 deletes key immediately [OK]

Common Mistakes:

• Thinking EXPIRE 0 removes expiration (never expires)
• Assuming EXPIRE syntax is wrong
• Believing SET must always have expiration

5. You want to cache user profile data in Redis but ensure it updates if the user changes their info. Which caching pattern is best?

hard

A. Set key with expiration and delete key on user update

B. Set key without expiration and never delete it

C. Set key with very long expiration and ignore updates

D. Do not cache user data at all

Solution

1. Step 1: Understand caching with data freshness

   To keep data fresh, cache keys should expire and be deleted when data changes.

2. Step 2: Evaluate options for update handling

   Set key with expiration and delete key on user update uses expiration and deletes key on update, ensuring fresh data. Others risk stale data or no caching.

3. Final Answer:

   Set key with expiration and delete key on user update -> Option A

4. Quick Check:

   Expire + delete on update keeps cache fresh [OK]

Hint: Expire keys and delete on update to keep cache fresh [OK]

Common Mistakes:

• Not deleting keys on data change
• Using no expiration causing stale cache
• Avoiding caching user data unnecessarily