Browser Cache vs Redis: Why Do We Need Redis If the Browser Can Cache Data?

Caching is one of those concepts that sounds simple:

Store something once, reuse it later, and avoid doing the expensive work again.

But once we start designing real applications, an important question appears:

If the browser can already cache data, why would we need something like Redis?

The answer is that browser caching and Redis operate at different layers of a system.

The browser primarily caches data close to the user.

Redis primarily provides shared, server-side storage for backend applications.

Understanding this distinction is important when designing scalable web applications.

First, What Is Caching?

Suppose we have an application that needs to retrieve a list of products.

Without caching:

Browser 
   | 
   | Request 
   v 
Backend 
   | 
   | Query 
   v 
Database 
   | 
   | Data 
   v 
Backend 
   | 
   v 
 Browser

Every request can potentially result in another database operation.

For example:

Request 1 → Database
Request 2 → Database
Request 3 → Database
Request 4 → Database

If the data doesn’t change frequently, repeatedly querying the database can be unnecessary.

Caching allows us to reuse previously retrieved data.

First request:
Application → Database → Cache

Later requests:
Application → Cache

The expensive operation can therefore be avoided.

Browser Caching

The first caching layer we encounter in web applications is often the browser.

The browser can store resources and responses locally.

For example:

User
 |
 v
Browser
 |
 +---- Browser Cache
 |
 v
Internet
 |
 v
Server

If a resource is already available in the browser’s cache and the caching rules allow it to be reused, the browser may not need to retrieve it from the server again.

This is particularly useful for things such as:

• JavaScript files
• CSS files
• images
• fonts
• static assets
• certain HTTP responses

This can significantly reduce network requests.

But Browser Cache Belongs to the Client

This is the first major difference.

Imagine we have three users:

User A Browser
     |
     | Cache A
     |
     v
   Server

User B Browser
     |
     | Cache B
     |
     v
   Server

User C Browser
     |
     | Cache C
     |
     v
   Server

Each browser has its own local cache.

User A’s cached data is not automatically available to User B.

This means browser caching is primarily client-specific.

Redis is different.

Redis Is Server-Side

Redis is an in-memory data store commonly used for caching and other backend workloads.

A typical architecture might look like this:

             Users
          /    |    \
         /     |     \
        v      v      v
     Browser Browser Browser
        \      |      /
         \     |     /
          v    v    v
          Load Balancer
                |
        +-------+-------+
        |       |       |
        v       v       v
     Server  Server  Server
        \       |      /
         \      |     /
              Redis
                |
                v
           PostgreSQL

Redis sits on the server side.

Multiple backend servers can access the same Redis instance or Redis deployment.

That makes Redis useful for shared application state and shared caching.

Browser Cache vs Redis

The simplest comparison is:

The important thing is that they are not competing caching technologies.

They can work together.

Example: Product Catalog

Imagine an e-commerce application.

We have:

GET /products

The database contains:

Products
---------
Laptop
Phone
Keyboard
Monitor
Mouse

Suppose thousands of users request the product catalog.

Without server-side caching:

User A → Backend → PostgreSQL
User B → Backend → PostgreSQL
User C → Backend → PostgreSQL
User D → Backend → PostgreSQL
...

The database receives many similar queries.

With Redis:

User A
   |
   v
Backend
   |
   v
Redis
   |
   | MISS
   v
PostgreSQL
   |
   v
Redis
   |
   v
User A

The backend can store the result:

products → [product data]

Then:

User B → Backend → Redis → Data
User C → Backend → Redis → Data
User D → Backend → Redis → Data

The database doesn’t necessarily need to execute the same query for every request.

Why Can’t the Browser Do This?

At first glance, we might say:

“Why not just cache the product list in every browser?”

We can.

And sometimes that is exactly what we should do.

But there is an important limitation.

Suppose the product catalog changes.

Database
    |
    | Product price changes
    v
New data

There could now be thousands of browsers containing different versions of the product data.

The server-side cache provides another layer where the application can control shared data.

For example:

Browser
   ↓
Backend
   ↓
Redis
   ↓
Database

Each layer has a different responsibility.

Multiple Backend Servers

This becomes even more important when an application scales horizontally.

Suppose we have three backend instances:

          Load Balancer
                  |
        +---------+---------+
        |         |         |
        v         v         v
     Server 1  Server 2  Server 3

Imagine each server keeps its own in-memory cache.

Server 1 → Cache A

Server 2 → Cache B

Server 3 → Cache C

Now the caches are independent.

A request handled by Server 1 might populate Cache A.

But the next request could go to Server 2.

Server 2 doesn’t have Server 1’s memory.

Redis can provide a shared caching layer:

     Server 1 ─┐
     Server 2 ─┼──→ Redis
     Server 3 ─┘

Now all backend instances can access the same cached data.

Get M. Ali Khan’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

This is one of the major architectural reasons for using Redis.

Browser Cache Doesn’t Solve Backend Work

Consider this request:

POST /generate-report

The backend might need to:

1. retrieve thousands of database records
2. process them
3. calculate statistics
4. generate a report
5. store the result

Browser caching doesn’t eliminate the backend computation for another user.

Redis can potentially store the result:

Report Request
      |
      v
   Backend
      |
      v
    Redis
      |
   +--+--+
   |     |
 HIT    MISS
   |     |
   |     v
   |   Compute
   |     |
   |     v
   |   Redis
   |     |
   +-----+
      |
      v
    User

Now multiple users requesting the same report may be able to reuse the server-side result.

Redis Is More Than a Cache

Another important distinction is that Redis isn’t simply a “faster browser cache.”

Redis is a server-side data structure store with capabilities that can support several backend patterns.

For example:

Caching

key → value

Rate limiting

user:123 → request_count

Counters

page_views → 15342

Sessions

session:abc123 → user information

Temporary state

verification:123456 → temporary information

Queues

Redis can also be used as part of job-processing architectures.

For example:

API
 |
 v
Redis Queue
 |
 +---- Worker 1
 |
 +---- Worker 2
 |
 +---- Worker 3

Browser caching cannot replace these backend responsibilities.

Browser Memoization Is Another Layer

There is also a distinction between browser caching and memoization.

Memoization usually means storing the result of a computation so that repeated calls can reuse it.

For example:

const cache = new Map();

function getUser(id) {
    if (cache.has(id)) {
        return cache.get(id);
    }
    const user = fetchUser(id);
    cache.set(id, user);
    return user;
}

The cache exists inside the application’s JavaScript runtime.

Conceptually:

Browser Application
       |
       +---- Memoization Cache
       |
       +---- Browser/HTTP Cache
       |
       v
     Backend
       |
       +---- Redis
       |
       v
    Database

Now we have multiple caching layers.

Different Caches Answer Different Questions

This is perhaps the most useful way to understand the architecture.

Browser memoization asks:

“Have I already calculated or fetched this in this application instance?”

Browser HTTP caching asks:

“Can I reuse this HTTP resource/response without retrieving it again?”

Redis asks:

“Has our backend system already computed or retrieved this data?”

Database asks:

“What is the actual persistent source of truth?”

So these aren’t necessarily alternatives.

They can form a hierarchy.

              User
               |
               v
        Browser Application
               |
        +------+------+
        |             |
   Memoization    HTTP Cache
        |             |
        +------+------+
               |
             HTTP
               |
               v
            Backend
               |
             Redis
               |
               v
          PostgreSQL

The Cache Hierarchy

A useful mental model is:

      Fastest / Closest
               ↑
               |
        Browser Memory
               |
        Browser Cache
               |
        Backend Memory
               |
             Redis
               |
          PostgreSQL
               |
               ↓
        Slower / Further Away

This isn’t a strict performance ranking for every implementation, but it illustrates the architectural idea:

The closer the cached data is to the consumer, the less work the system may need to do.

However, the closer cache also tends to have a smaller scope.

Browser memory belongs to one application instance.

Redis can be shared by an entire backend system.

When You Don’t Need Redis

This is important because Redis shouldn’t automatically be added to every application.

If your application is:

Browser → Backend → PostgreSQL

and the database workload is small, adding Redis may simply introduce another component to operate.

You might not need it.

For example:

Small application
      |
      v
Backend
      |
      v
PostgreSQL

can be perfectly reasonable.

You should introduce Redis when there is an actual requirement for things such as:

• shared caching
• reducing expensive database queries
• distributed state
• rate limiting
• queues
• temporary server-side data
• coordination between services

The Real Architectural Answer

The question isn’t:

“Browser cache or Redis?”

The better question is:

“Where should this data be cached, and who needs to share it?”

If only one browser needs the data:

Browser → Local Cache

may be enough.

If many backend instances need the same data:

Backend Instances
       |
       v
     Redis

makes more sense.

If the data must survive as the authoritative source:

PostgreSQL

is the appropriate persistent storage layer.

Conclusion

Browser caching and Redis solve different problems.

Browser caching reduces work between the user’s browser and the server.

Redis reduces work inside the backend system and can provide shared server-side state.

A production application may therefore use both:

                    USERS
                      |
                      v
               ┌─────────────┐
               │   Browser   │
               │             │
               │ Memoization │
               │ HTTP Cache  │
               └──────┬──────┘
                      |
                    HTTP
                      |
                      v
               ┌─────────────┐
               │   Backend   │
               └──────┬──────┘
                      |
                      v
               ┌─────────────┐
               │    Redis    │
               │             │
               │ Shared Cache│
               │ Rate Limits │
               │ Queues      │
               │ State       │
               └──────┬──────┘
                      |
                      v
               ┌─────────────┐
               │ PostgreSQL  │
               │ Source of   │
               │   Truth     │
               └─────────────┘

The key idea is simple:

Caching isn’t one technology. It’s a strategy applied at different layers of an architecture.

Browser caching optimizes the client side.

Redis can optimize the server side.

And neither automatically replaces the other.