DEV Community: Mohammad Abdullah

Redis Is Not Your Database: Designing Cache Failures, Fallbacks, and Resilient Backends

Mohammad Abdullah — Sun, 13 Sep 2026 17:54:34 +0000

Redis can make a backend dramatically faster.

It can also make a backend dramatically more fragile if the architecture treats the cache as a dependency that must always be available.

The distinction is simple:

A database stores authoritative data. A cache stores data that can be recreated.

Once that distinction is understood, Redis failure becomes an architectural problem rather than simply an infrastructure outage.

The Cache-Aside Pattern

Consider a Node.js backend serving product information.

Without caching:

             Client
               │
               ▼
           Node.js API
               │
               ▼
            Database
               │
               ▼
            Response

With Redis:

             Client
               │
               ▼
            Node.js API
               │
               ▼
             Redis
               │
               ├── Cache Hit ─────► Response
               │
               └── Cache Miss
               │
               ▼
             Database
               │
               ▼
             Redis SET
               │
               ▼
             Response

This reduces repeated database reads and can significantly improve response latency for frequently accessed data.

But caching introduces a new dependency and therefore a new failure mode.

What Happens When Redis Goes Down?

Suppose the API expects Redis to be available for every request.

A naive implementation might do this:

             Request
               │
               ▼
             Redis
               │
               X
             Redis unavailable
               │
               ▼
             Request fails

That is often unnecessary.

If Redis only contains cached data, the application may safely fall back to the primary datastore:

                Request
                  │
                  ▼
                Redis
                  │
                  X
                unavailable
                  │
                  ▼
                Database
                  │
                  ▼
                Response

This is a much better failure model.

But it is not the end of the problem.

The Dangerous Fallback

Imagine Redis normally handles 90% of read traffic.

Now Redis fails.

Suddenly:

                              Normal
              1000 requests ─────────────►
                              Redis
                                ↓
                            Database
                               100

After Redis fails:

                               Redis DOWN
                 1000 requests ─────────────► Database
                                     │
                                     ▼
                            Database overloaded
                                     │
                                     ▼
                                API latency ↑
                                     │
                                     ▼
                                  Timeouts ↑
                                     │
                                     ▼
                                 More retries
                                     │
                                     ▼  
                                More overload

The fallback has created a failure cascade.

This is one of the most important lessons in distributed systems:

A fallback can move the failure rather than eliminate it.

Timeouts Are a Reliability Feature

A common mistake is allowing an API request to wait indefinitely for Redis.

If Redis is slow, every request waiting on Redis consumes application resources.

Instead, external dependencies should have deliberate timeouts.

Conceptually:

                        API Request
                            │
                            ▼
                       Redis request
                            │
                            ├── Fast response ──► Continue
                            │
                            └── Timeout ────────► Fallback

The timeout should be based on the application's latency requirements rather than an arbitrary number.

A cache that normally responds in milliseconds should not be allowed to hold an API request for several seconds before the application decides it is unavailable.

Circuit Breakers Prevent Repeated Failure

If Redis is continuously failing, repeatedly attempting Redis requests is wasteful.

A circuit breaker changes the behavior:

                  Redis healthy
                       │
                       ▼
                     CLOSED
                       │
                  repeated failures
                       │
                       ▼
                     OPEN
                       │
                 skip Redis calls
                       │
                       ▼
                   Database

After a controlled recovery period, the circuit can allow limited requests to test whether Redis has recovered.

This prevents every request from repeatedly hitting a known unhealthy dependency.

Retries Can Make an Outage Worse

Retries are useful for transient failures.

But retries are dangerous when they are uncontrolled.

Suppose 1,000 requests fail because Redis is unavailable.

If every request retries three times:

           1,000 original requests
                    × 
                3 retries
                    =
           3,000 additional attempts

The dependency is already unhealthy, and the application is now generating more traffic toward it.

This is why retries should generally be paired with:

timeouts,
exponential backoff,
retry limits,
jitter,
circuit breakers.

The goal is not to retry forever.

The goal is to distinguish transient failure from persistent failure.

Cache Stampede: Another Hidden Failure

There is another scenario worth considering.

Suppose a popular cached value expires at the same time for thousands of users.

Instead of:

                  Redis ──► cached response

               thousands of requests simultaneously execute:

                         Redis MISS
                              ↓
                           Database
                              ↓
                           Database
                              ↓
                           Database
                              ↓
                           Database
                              ↓
                             ...

This is commonly called a cache stampede.

Possible mitigation strategies include:

                   TTL randomization,
                   request coalescing,
                   stale-while-revalidate,
                   background refresh,
                   controlled cache warming.

The important lesson is that cache expiration is itself a traffic event.

Stale Data Can Be Better Than No Data

Not every piece of data requires perfect freshness.

For example, a product catalog, configuration metadata, or public article may tolerate slightly stale information.

In those cases, serving a stale value can be better than failing the request.

Conceptually:

                           Fresh cache
                                │
                                ▼
                         Return immediately

                      Fresh cache unavailable
                                │
                                ▼
                       Stale value available?
                                │
                                ├── Yes ──► Return stale value
                                │
                                └── No ───► Query database

This is an example of graceful degradation.

The system preserves useful functionality even when one component is unhealthy.

Redis Should Have a Clear Responsibility

A clean architecture establishes boundaries.

                       Database:

                    Source of truth

                       Redis:

                    Performance optimization

                       Node.js:

                    Application and business logic

                      Load balancer:

                    Traffic distribution

                      Monitoring:

                    Detection and diagnosis

Once responsibilities are clear, failure behavior becomes easier to reason about.

If Database fails, the application has a fundamentally different problem than if Redis fails.

If Redis fails, the system may degrade in performance.

If the primary database fails, the system may lose its source of truth.

Treating both failures identically is an architectural mistake.

Monitor the Cache, Not Just the Application

A backend can report HTTP 200 responses while quietly becoming unhealthy.

Useful cache metrics include:

                      cache hit ratio,
                      cache miss ratio,
                      Redis latency,
                      connection errors,
                      timeout rate,
                      memory usage,
                      eviction rate,
                      command latency,
                      connection count.

A falling cache hit rate may indicate that the cache is undersized, poorly keyed, expiring too aggressively, or simply not providing enough value for the workload.

The goal of observability is not to collect every metric possible. It is to detect behavior that requires action. AWS similarly recommends monitoring all workload components and reviewing whether monitoring coverage and thresholds remain appropriate.

Test Redis Failure Before Production Finds It

A resilient design should be tested intentionally.

For example:

                      Test 1:
                      Stop Redis
                          ↓
                  Does the API remain available?

                      Test 2:
                      Add Redis latency
                          ↓
                  Do API timeouts remain bounded?

                      Test 3:
                      Generate high read traffic
                          ↓
                  Does Database survive cache failure?

                      Test 4:
                      Expire a popular key
    ↓

Does a cache stampede occur?

These tests reveal something a normal happy-path test cannot:

how the system behaves when dependencies stop behaving normally.

Failure testing is a core part of resilience engineering because recovery behavior should be understood before a real incident forces the lesson.

The Real Goal Is Not "Redis Never Fails"

Infrastructure will fail.

Networks become unreliable. Instances disappear. Services become slow. Deployments introduce bugs. Dependencies experience outages.

The goal of resilient architecture is therefore not:

Prevent every failure.

It is:

Limit the impact of failure and recover predictably.

For Redis, that usually means:

                     Redis healthy
                          │
                          ▼
                   Fast cache responses
                          │
                          │ failure
                          ▼
                    Bounded timeout
                          │
                          ▼
                   Fallback to database
                          │
                          ▼
                   Protect database from overload
                          │
                          ▼
                      Recover Redis
                          │
                          ▼
                   Resume normal caching

A cache should make your application faster, not make its availability dependent on the cache.

That is the architectural difference between simply adding Redis and actually designing a resilient backend.

Building a Production-Ready MERN Application on AWS: From Deployment to Resilience

Mohammad Abdullah — Sun, 13 Sep 2026 17:21:35 +0000

Building a MERN application is relatively straightforward. Building one that remains reliable when traffic increases, an instance fails, a cache disappears, or a deployment goes wrong is a very different engineering problem.

A production deployment should therefore be designed around more than application availability. It should consider scalability, failure recovery, observability, security, deployment safety, and operational cost from the beginning.

AWS describes reliability as the ability of a workload to perform its intended function consistently and to recover from disruptions throughout its lifecycle. That changes the question from “How do I deploy my MERN application?” to “How will this application behave when something goes wrong?”

Start With the Architecture, Not the Server

A typical MERN stack contains React, Node.js/Express, MongoDB, and supporting services such as Redis. On AWS, these components should not simply be placed on a single EC2 instance because it is easy.

A more production-oriented architecture separates responsibilities:

                Users
                  │
                  ▼
           Route 53 / DNS
                  │
                  ▼
             CloudFront
                  │
                  ▼
          Application Load
             Balancer
                  │
         ┌────────┴────────┐
         ▼                 ▼
      Node.js            Node.js
      Instance           Instance
         │                 │
         └────────┬────────┘
                  │
         ┌────────┴────────┐
         ▼                 ▼
      Redis              Database
      Cache              (SQL/NoSQL)

The important part is not the number of AWS services. It is the separation of concerns.

The frontend should not depend on the lifecycle of the backend server. The backend should not depend on local filesystem state. The cache should not become the system of record. And a single application instance should not represent the availability of the entire service.

Compute Should Be Replaceable

One of the most useful production principles is to treat application instances as replaceable compute.

If an EC2 instance disappears, the application should be able to start elsewhere without losing important application state.

That means avoiding designs where:

uploaded files exist only on local disk,
sessions exist only in process memory,
configuration is manually changed on the server,
deployments require undocumented manual steps,
application state depends on a particular machine.

This is where load balancing and horizontal scaling become valuable.

Instead of making one server increasingly powerful, multiple application instances can serve requests behind a load balancer.

             Load Balancer
             /            \
            /              \
      App Instance A   App Instance B
            \              /
             \            /
               Database

If one instance becomes unhealthy, traffic can be directed toward healthy resources. AWS explicitly recommends monitoring components, failing over to healthy resources, and automating healing when designing workloads to withstand component failures.

The Database Is a Different Problem

Scaling the application layer does not automatically solve database scalability.

If five Node.js instances all depend on one database, the database can become the bottleneck even though the application tier has plenty of capacity.

Therefore, production architecture should consider:

              query efficiency,
              indexes,
              connection pooling,
              read/write patterns,
              database scaling,
              backups,
              replication,
              recovery objectives.

The correct database strategy depends on workload characteristics. Scaling compute alone is often not enough; data access patterns and load testing should influence the architecture.

Redis Should Improve Performance, Not Define Availability

Redis is often introduced to reduce database load and improve latency.

A common cache-aside flow looks like this:

                 Request
                   │
                   ▼
               Check Redis
                   │
                   ├── Hit ──────► Return cached data
                   │
                   └── Miss
                   │
                   ▼
                Database
                   │
                   ▼
              Store in Redis
                   │
                   ▼
               Return data

The critical design decision is what happens when Redis is unavailable.

If Redis is merely a cache, its failure should not necessarily mean that the entire application becomes unavailable.

The application may temporarily bypass the cache and retrieve data from the primary datastore.

However, that introduces another problem: a cache failure can create a database overload.

This is why resilience must be considered as a system rather than component by component.

Deployments Are Also Failure Scenarios

A deployment can fail even when the application itself is perfectly healthy.

A production deployment strategy should therefore minimize blast radius.

Instead of changing everything at once:

         Version 1 ───────────────► Version 2
                    BIG RISK

         use smaller, controlled changes:

         Version 1 ──► small deployment ──► observe ──► expand

Blue/green, rolling, and canary strategies can all reduce deployment risk when applied appropriately.

Automated CI/CD is valuable not because automation is fashionable, but because repeatable deployment reduces manual error and makes rollback practical.

AWS recommends frequent, small, reversible changes because they reduce blast radius and make recovery easier.

Observability Is Part of the Architecture

A production application should answer basic questions quickly:

Is the API healthy?
Which endpoint is slow?
Are error rates increasing?
Is the database saturated?
Is Redis failing?
Are requests timing out?
Did latency increase after the latest deployment?

Logs alone are not enough.

A useful observability strategy combines:

Metrics + Logs + Traces + Alerts

For example:

              Request
                │
                ├── API latency
                ├── HTTP status
                ├── database latency
                ├── Redis latency
                └── application logs

Observability should produce actionable information, not simply generate dashboards full of graphs. AWS specifically recommends using telemetry to understand workload behavior, reliability, performance, cost, and health.

Security Is Not a Final Step

Production architecture should also assume that infrastructure will eventually be exposed to hostile traffic.

Use:

HTTPS everywhere,
least-privilege IAM,
security groups with minimal exposure,
secrets management rather than hard-coded credentials,
protected database access,
secure environment configuration,
dependency and container scanning where appropriate.

The backend should not expose MongoDB or Redis directly to the public internet simply because the application needs access to them.

A useful rule is:

Public access should be intentional; private communication should be the default.

Test What Happens When Things Break

The strongest production architecture is not the one that looks perfect in a diagram. It is the one whose failure behavior is understood.

Test scenarios such as:

                        EC2 instance fails
                              ↓
               Does traffic move to another instance?

                          Redis fails
                              ↓
                 Does the API continue operating?

                      Database becomes slow
                              ↓
                  Do requests time out safely?

                        Deployment fails
                              ↓
                 Can the previous version be restored?

                       Traffic increases
                              ↓
                Does the system scale without collapsing?

AWS recommends actively testing failure scenarios, including functional, performance, and resilience testing, because understanding system behavior during failures improves recovery.

Production Readiness Is a Property of the Whole System

A MERN application does not become production-ready merely because it is running on AWS.

Production readiness emerges from the interaction of:

Architecture + Security + Automation + Observability + Scalability + Failure Recovery

The most important shift is to stop thinking only about successful requests.

A production engineer also asks:

What happens when this dependency is slow?

What happens when this instance disappears?

What happens when traffic suddenly increases?

What happens when the deployment fails?

What happens when the cache is unavailable?

Those questions turn a deployed MERN application into a resilient production system.