Modern applications are expected to respond quickly, even when they serve thousands or millions of users. However, repeatedly fetching the same data from databases, APIs, or remote servers can increase latency and put unnecessary pressure on backend infrastructure.
This is where caching becomes an important part of system design.
Caching stores frequently accessed or expensive-to-compute data in a faster location so future requests can be served more quickly. Instead of performing the same database query or API request repeatedly, an application can retrieve previously stored data from a cache.
For example:
Without Cache
User
↓
Application Server
↓
Database
↓
Application Server
↓
User
With caching:
User
↓
Application Server
↓
Cache
↓
User
If the requested data is available in the cache, the application may avoid accessing the database entirely.
Caching can significantly improve:
- Application performance
- Response times
- Scalability
- Database efficiency
- User experience
In this guide, you’ll learn what caching is, how it works in system design, the role of Redis and CDNs, common cache strategies, cache eviction policies, cache invalidation, and common caching mistakes.
What Is Caching?
Caching is the process of storing frequently accessed data in a fast storage layer so it can be retrieved more quickly in future requests.
A cache acts as a temporary storage layer between an application and a slower data source.
For example:
Application
↓
Cache
↓
Database
When an application receives a request, it can first check whether the required data exists in the cache.
Request
↓
Check Cache
↓
┌───────────────┐
│ Cache Hit? │
└───────────────┘
↓ ↓
Yes No
↓ ↓
Return Database
Cached Data ↓
Store in Cache
↓
Return Data
This basic flow is one of the most common caching patterns in modern applications.
Why Is Caching Important in System Design?
Without caching, every request may need to reach the database or another backend service.
Imagine a popular product page receiving thousands of requests every minute.
Without caching:
1,000 Users
↓
1,000 Database Queries
With caching:
1,000 Users
↓
Cache
↓
Few Database Queries
The cache can serve many repeated requests without forcing the database to perform the same work repeatedly.
Caching helps with several important system design goals.
Better Performance
Frequently requested data can be returned faster.
Lower Latency
The application may avoid slower database queries or remote API calls.
Reduced Database Load
Repeated requests can be handled by the cache.
Improved Scalability
The system can serve more users without proportionally increasing database workload.
Better User Experience
Faster applications generally provide a smoother user experience.
How Does Caching Work?
A typical caching flow looks like this:
Step 1: A User Requests Data
For example:
GET /products/123
Step 2: The Application Checks the Cache
Application
↓
Check Cache
Step 3: Cache Hit or Cache Miss
Cache Hit
The requested data already exists in the cache.
Request
↓
Cache ✓
↓
Return Data
The application can return the data quickly.
Cache Miss
The requested data does not exist in the cache.
Request
↓
Cache ✗
↓
Database
The application retrieves the data from the original source.
Step 4: Store the Data in the Cache
After retrieving the data:
Database
↓
Application
↓
Cache
↓
User
Future requests may then be served directly from the cache.
What Is Redis?
Redis is an in-memory data store commonly used for caching, session storage, rate limiting, and other high-speed data operations.
Because Redis primarily stores data in memory, it can provide very fast access compared with repeatedly querying a traditional disk-based database.
A common architecture looks like this:
Users
↓
Application Server
↓
Redis Cache
↓
Database
The application first checks Redis.
If the data exists:
Redis
↓
Return Data
If the data does not exist:
Redis Miss
↓
Database
↓
Redis
↓
User
Common Redis Use Cases
Redis can be used for several system design problems.
1. Application Caching
Store frequently accessed data.
Examples:
- Product information
- User profiles
- Popular posts
- Application configuration
2. Session Storage
Instead of storing sessions on individual application servers:
Server 1 → Local Session
Server 2 → Local Session
Server 3 → Local Session
A shared Redis instance can store session data.
Server 1 ──┐
Server 2 ──┼── Redis
Server 3 ──┘
This can make scaling application servers easier.
3. Rate Limiting
Redis can help track request counts.
For example:
User Request
↓
Redis Counter
↓
Requests This Minute
If a user exceeds a defined limit, the application can reject or delay additional requests.
4. Leaderboards and Counters
Redis can be useful for fast counters and ranking data.
Examples include:
- Game leaderboards
- View counts
- Like counts
- Real-time metrics
What Is a CDN Cache?
A Content Delivery Network (CDN) can cache and deliver static or cacheable content from locations closer to users.
This is especially useful for:
- Images
- Videos
- JavaScript files
- CSS files
- Static website content
Without a CDN:
User in India
↓
Origin Server
↓
Content Returned
With a CDN:
User
↓
Nearby CDN Edge Server
↓
Cached Content
The user may receive content from a geographically closer location.
CDN Caching in System Design
A common architecture may look like this:
Users
↓
CDN
↓
Load Balancer
↓
Application Servers
↓
Cache
↓
Database
Different types of data can be cached at different layers.
For example:
Static Images
↓
CDN Cache
API Data
↓
Application Cache / Redis
Persistent Data
↓
Database
This is known as using multiple layers of caching.
Types of Caching
Caching can happen at several levels in an application.
1. Client-Side Caching
Data is cached on the user’s device or browser.
Examples include:
- Browser caching
- Local application caching
- Cached static assets
Browser
↓
Local Cache
This can reduce unnecessary network requests.
2. CDN Caching
Content is cached at edge locations.
User
↓
CDN Edge Cache
This is especially useful for static assets and globally distributed users.
3. Application-Level Caching
The application itself manages cached data.
Application
↓
Redis / Memory Cache
4. Database Caching
Some database systems internally cache frequently accessed data.
Applications may also use database query caching depending on the technology and architecture.
Cache-Aside Strategy
The Cache-Aside pattern is one of the most common caching strategies.
The application is responsible for managing the cache.
The flow works like this:
1. Check Cache
↓
2. Cache Hit?
↓ ↓
Yes No
↓ ↓
Return Database
Data ↓
Store in Cache
↓
Return Data
Example:
Request Product
Check Redis
↓
Product Found?
↓ ↓
Yes No
↓ ↓
Return Database
Cache ↓
Redis
This approach gives developers significant control over cache behavior.
Write-Through Cache
In a write-through strategy, data is written to the cache and the primary database during a write operation.
Application
↓
Cache
↓
Database
The cache is updated when the data changes.
This can help keep cached data synchronized with the primary data source.
Write-Behind Cache
With a write-behind strategy, data is first written to the cache.
The database update may happen asynchronously.
Application
↓
Cache
↓
Async Database Write
This can improve write performance in some scenarios but introduces additional reliability and consistency considerations.
Read-Through Cache
In a read-through cache, the application retrieves data through the cache layer.
Application
↓
Cache
↓ ↓
Hit Miss
↓ ↓
Data Database
The cache layer is responsible for retrieving missing data from the source.
Cache Invalidation
One of the most difficult parts of caching is ensuring that cached data does not become outdated.
Imagine a product price changes.
Database Price → $50
Cache Price → $40
Users may receive incorrect information if the cache is not updated.
This is called stale data.
Cache invalidation means removing or updating cached data when the original data changes.
Common Cache Invalidation Strategies
1. Time-to-Live (TTL)
A cached item automatically expires after a specified period.
Example:
Product Cache
TTL: 10 Minutes
After expiration:
Cache Expires
↓
Next Request
↓
Database
↓
New Cache Entry
TTL is simple and commonly used.
2. Explicit Invalidation
When data changes, the application explicitly removes or updates the cache.
Update Product
↓
Update Database
↓
Invalidate Cache
The next request retrieves fresh data.
3. Event-Based Invalidation
An event can trigger cache updates or invalidation.
Product Updated
↓
Event
↓
Invalidate Cache
This can be useful in distributed systems.
Cache Eviction Policies
A cache has limited storage.
When the cache becomes full, it needs to decide which data to remove.
This process is called cache eviction.
1. LRU — Least Recently Used
The least recently accessed item is removed first.
Frequently Used → Keep
Rarely Used → Remove
LRU is a common caching policy.
2. LFU — Least Frequently Used
The item accessed the fewest times is removed.
High Usage → Keep
Low Usage → Remove
3. FIFO — First In, First Out
The oldest cached item is removed first.
First Stored
↓
First Removed
Cache Hit Rate
The cache hit rate measures how often requests are served from the cache.
For example:
Total Requests: 1,000
Cache Hits: 900
Cache Misses: 100
The cache hit rate is:
90%
A higher cache hit rate can indicate that frequently requested data is being effectively served from the cache.
However, a high hit rate alone does not guarantee that the caching strategy is optimal. Cache freshness, memory usage, and workload patterns also matter.
Cache Stampede
A cache stampede can happen when a popular cached item expires and many requests try to regenerate it at the same time.
For example:
Popular Cache Entry Expires
↓
10,000 Requests Arrive
↓
10,000 Database Queries
This can overload the database.
Possible approaches to reduce this problem include:
- Locking
- Request coalescing
- Stale-while-revalidate strategies
- Early refresh techniques
The correct approach depends on the application.
Stale-While-Revalidate
With stale-while-revalidate, an application can temporarily return cached data while refreshing it in the background.
User Request
↓
Return Existing Cache
↓
Background Refresh
↓
Update Cache
This can reduce latency while keeping data reasonably fresh.
Cache Warming
Cache warming means populating the cache before users request data.
For example:
Popular Data
↓
Preload into Cache
↓
Users Request Data
↓
Cache Hit
This can be useful before:
- Product launches
- Major sales
- High-traffic events
Redis vs CDN Caching
Redis and CDNs solve different caching problems.
| Feature | Redis | CDN |
|---|---|---|
| Main Location | Application infrastructure | Edge locations |
| Best For | Dynamic application data | Static and cacheable content |
| Common Data | Sessions, API data, counters | Images, CSS, JavaScript |
| Main Goal | Reduce backend latency and load | Reduce network latency |
| Used By | Backend applications | Users and browsers |
In many systems, Redis and a CDN are used together.
Users
↓
CDN
↓
Application
↓
Redis
↓
Database
Multi-Layer Caching
Large systems often use more than one cache.
For example:
Browser Cache
↓
CDN Cache
↓
Application Cache
↓
Database
Each layer reduces load on the next.
Browser Cache
↓
Fewer CDN Requests
CDN Cache
↓
Fewer Application Requests
Application Cache
↓
Fewer Database Queries
This approach can improve performance at scale.
Common Caching Strategies in System Design
Here are some of the most common approaches.
Cache Frequently Read Data
Data that is read often but changes infrequently is often a good caching candidate.
Examples:
- Product information
- Public profiles
- Configuration data
Avoid Caching Everything
Caching everything can create unnecessary complexity.
Consider:
- How frequently is the data requested?
- How frequently does the data change?
- How expensive is it to retrieve?
- How important is data freshness?
Use Appropriate TTL Values
A very short TTL may cause frequent database requests.
A very long TTL may serve outdated data.
Choose expiration periods based on the data’s requirements.
Monitor Cache Performance
Monitor:
- Cache hit rate
- Cache miss rate
- Memory usage
- Eviction rate
- Response times
Monitoring helps identify whether the cache is actually improving the system.
Common Caching Mistakes
1. Treating the Cache as the Source of Truth
In most architectures, a cache is not the primary source of persistent data.
The database or another durable storage system typically remains the source of truth.
2. Ignoring Cache Invalidation
A fast application is not useful if it consistently returns incorrect data.
Always consider what happens when the original data changes.
3. Using the Same TTL for Everything
Different types of data have different freshness requirements.
For example:
Product Price → Short TTL
Website Logo → Long TTL
4. Not Planning for Cache Failure
What happens if Redis becomes unavailable?
A resilient system should consider fallback behavior.
For example:
Redis Available?
↓
Yes → Use Cache
No
↓
Database Fallback
5. Causing a Cache Stampede
Popular cache entries may create sudden pressure on databases when they expire.
Consider appropriate strategies for high-traffic data.
Caching in a Complete System Architecture
A modern application might look like this:
Users
↓
Browser Cache
↓
CDN
↓
Load Balancer
↓
Application Servers
↓
Redis Cache
↓
Database
Each layer has a specific purpose.
| Component | Primary Purpose |
|---|---|
| Browser Cache | Reduce repeated client requests |
| CDN | Deliver cached content closer to users |
| Load Balancer | Distribute traffic |
| Application Servers | Process application logic |
| Redis | Cache application data |
| Database | Store persistent data |
This architecture combines multiple system design concepts.
Example: Caching an E-Commerce Product
Imagine thousands of users viewing the same product.
Without caching:
User
↓
Application
↓
Database Query
Repeated thousands of times.
With caching:
User
↓
Application
↓
Redis
Cache Hit?
↓
Yes → Return Product
Only cache misses may need to query the database.
This can significantly reduce repeated database work.
When Should You Use Caching?
Caching is useful when:
- Data is frequently requested.
- Retrieving data is expensive.
- Low latency is important.
- Data does not change on every request.
- Backend infrastructure is under heavy read load.
Caching may be less suitable when:
- Data changes extremely frequently.
- Every request requires completely fresh data.
- Incorrect or stale data could cause serious problems.
The correct decision depends on the application’s requirements.
Frequently Asked Questions
What Is Caching in System Design?
Caching is the process of storing frequently accessed data in a faster storage layer so future requests can be served more quickly without repeatedly accessing the original data source.
What Is Redis Used for in System Design?
Redis is commonly used for caching, session storage, rate limiting, counters, leaderboards, and other workloads that benefit from fast in-memory data access.
What Is the Difference Between Redis and a CDN?
Redis is commonly used inside application infrastructure to cache dynamic data and support fast backend operations. A CDN caches and delivers static or cacheable content closer to users through geographically distributed edge locations.
What Is a Cache Hit?
A cache hit occurs when the requested data is found in the cache and can be returned without accessing the original data source.
What Is a Cache Miss?
A cache miss occurs when the requested data is not available in the cache, so the application must retrieve it from the database or another source.
What Is Cache Invalidation?
Cache invalidation is the process of removing or updating cached data when the original data changes to prevent users from receiving outdated information.
What Is the Cache-Aside Pattern?
Cache-aside is a caching strategy where the application checks the cache first and retrieves missing data from the primary data source. The application then stores the retrieved data in the cache for future requests.
Conclusion
Caching is one of the most important performance and scalability techniques in system design.
It reduces repeated work by storing frequently accessed data in faster locations.
Different caching layers solve different problems:
- Browser caching reduces repeated client requests.
- CDNs deliver cached content closer to users.
- Redis provides fast access to frequently used application data.
- Application caching reduces database and backend workload.
However, caching also introduces challenges.
Developers must consider:
- Cache invalidation
- Data freshness
- TTL values
- Cache eviction
- Cache failures
- Cache stampedes
The best caching strategy is not simply storing as much data as possible.
A good caching strategy starts by identifying what data is expensive to retrieve, how frequently it is requested, how quickly it changes, and how much stale data the application can tolerate.
When used correctly, caching can significantly improve performance, reduce infrastructure load, and help applications scale to handle larger numbers of users.
