Redis Caching

Day 1/100 of System design.

When Healthcare.gov launched a few years back, it was supposed to be the big moment, millions of Americans rushing online to sign up for health coverage. Instead, it turned into a digital traffic jam. Pages crawled, forms froze, and countless users couldn’t even finish registration. The culprit? Not bad code, not bad intentions ; just sheer overwhelming load. The backend servers and, most importantly, the database were drowning under millions of repetitive queries.

Sound familiar? It’s the same pattern as our Lagos bakery story from Day 0 — more customers than one cashier (or in this case, one database) could ever handle. The lesson is clear: scaling servers isn’t enough. If the database keeps getting slammed with the same requests over and over, no amount of extra horsepower will save you

Why Caching Matters

Think of caching as the bakery hiring an assistant whose only job is to answer the most common questions. Instead of every customer asking, “Do you have Agege bread today?” and making the cashier stop to check each time, the assistant has a sign ready: “Yes, we do, ₦500 per loaf!”

That’s caching.

After scaling out servers (more cashiers), the next battle is speed. Without caching, every single user request, no matter how common, has to hit the database, which is slower and more expensive. With caching, frequently accessed data gets stored in a faster, lighter storage layer, ready to be served instantly.

The result? Users get quick answers, the database breathes easier, and the system feels smooth even under heavy traffic.

Different Approaches to Caching

Now here’s the catch: not all caching is the same. Just like bakeries can hire different types of assistants (one who writes on a board, one who shouts updates, or one who handles a VIP queue), systems have different caching strategies depending on their goals and constraints.

Before we dive into Redis (one of the most popular caching tools today), it’s worth exploring the main approaches to caching and where they shine.

In-Memory Hash Maps

For small or simple apps, the easiest caching strategy is to keep frequently used data directly in memory using something like a dictionary in Python or an object in Node.js. This approach is blazing fast because everything stays within a single instance.

But there’s a catch: it doesn’t scale across multiple servers, and if the app restarts, the cache disappears (volatile memory). While this can be Great for a quick prototype, it is very risky for production.

Memcached

Memcached is a widely used distributed caching system known for lightweight, simple key-value storage. The trade-off? It’s limited to simple data types and doesn’t offer persistence or complex structures. Think of it as a reliable motorbike, quick, efficient, but not built for carrying heavy loads.

Hazelcast and KeyDB

If you need clustering, fault tolerance, or multi-threaded performance enhancements, Hazelcast (a distributed in-memory data grid) or KeyDB (a high-performance fork of Redis) may be preferable. They bring advanced capabilities but add operational complexity.

Choosing the Right Fit

Each method shines in its own lane:

• Simple maps → small apps, prototypes, one-server setups.

• Memcached → mid-sized services needing speed without complexity.

• Redis / KeyDB / Hazelcast → large-scale, distributed systems that need resilience and richer features.

This is why Redis became the industry favorite: it strikes a balance between speed, flexibility, and ecosystem support.

What Is Caching? (The Big Picture)

Caching is like your brain’s short-term memory. When you learn a fact, you don’t keep relearning it; you recall it quickly while it’s fresh. Systems work the same way: caching temporarily stores data in faster storage, so apps don’t have to fetch or compute it over and over again.

The payoff is huge:

• Lower latency and faster responses

• Reduced database load and compute usage

• Better user experience with snappier interactions

The Redis Edge

Redis is an open-source, in-memory data store that keeps data in RAM, enabling microsecond response times. It supports advanced structures beyond simple key-values, persistence modes, and rich features like TTL (time-to-live) and eviction strategies to handle memory efficiently.

Because of these strengths and active community support, Redis is the most popular cache choice in modern systems.

How Redis Caching Works: The Cache-Aside Pattern

The dominant pattern for caching data in Redis is cache-aside or lazy loading. Here’s how it looks in practice:

1. The application checks Redis for the requested data first.

2. If found (cache hit), it immediately returns that data.

3. If not found (cache miss), it queries the slower database, returns the data to the user, and writes it back into Redis with a TTL.

This balances speed and data freshness nicely.

Example: Cache-Aside in Python

import redis

# Create a Redis client (default localhost:6379)
redis_client = redis.Redis(host='localhost', port=6379, db=0)

def get_data(key):
    try:
        # 1. Check Redis cache
        cached = redis_client.get(key)
        if cached:
            return cached.decode('utf-8')  # Cache hit

        # 2. Cache miss → fetch from DB
        data = db_query(key)

        # 3. Write back to cache with 1-hour TTL
        redis_client.setex(key, 3600, data)  # TTL = 3600s = 1hr

        return data

    except redis.exceptions.RedisError as e:
        # Fallback gracefully if Redis is unavailable
        print(f"Redis error: {e}")
        return db_query(key)

def db_query(key):
    # Simulated DB query (replace with real DB call)
    return f"data_for_{key}"

Here’s a simple Python implementation of the cache-aside pattern with Redis. The function first checks Redis: if the data exists, it’s returned instantly (cache hit). If not, the app falls back to the database (cache miss), then stores the result in Redis with a one-hour TTL. Notice the error handling — if Redis is down, the app still works by going directly to the database.

Here’s the same cache-aside pattern in Node.js using ioredis. The app first checks Redis. If data is present, it’s returned instantly (cache hit). If not, it queries the database (cache miss) and stores the fresh result in Redis with a one-hour TTL. Notice the try/catch — even if Redis fails, the app still falls back to the database.

const Redis = require('ioredis');
const redis = new Redis(); // defaults to localhost:6379

async function getData(key) {
  try {
    // 1. Check Redis cache
    const cached = await redis.get(key);
    if (cached) {
      return cached; // Cache hit
    }

    // 2. Cache miss → fetch from DB
    const data = await dbQuery(key);

    // 3. Store result in Redis with 1-hour TTL
    await redis.set(key, data, 'EX', 3600); // TTL = 3600s = 1hr

    return data;

  } catch (err) {
    console.error("Redis error:", err);
    // Fallback → query DB directly if Redis is unavailable
    return dbQuery(key);
  }
}

async function dbQuery(key) {
  // Simulate DB fetching (replace with real DB call)
  return `data_for_${key}`;
}

And a Java example using Jedis:

import redis.clients.jedis.Jedis;
import redis.clients.jedis.exceptions.JedisException;

public class CacheExample {
    static Jedis jedis = new Jedis("localhost");

    public static String getData(String key) {
        try {
            String cached = jedis.get(key);
            if (cached != null) return cached;

            String data = dbQuery(key);
            jedis.setex(key, 3600, data); // set with TTL
            return data;
        } catch (JedisException e) {
            // Log the error and fall back to DB
            System.err.println("Redis error: " + e.getMessage());
            return dbQuery(key);
        }
    }

    private static String dbQuery(String key) {
        // Mock DB fetch
        return "data_for_" + key;
    }
}

Finally, a .NET example with StackExchange.Redis:

csharpusing StackExchange.Redis;
using System;

public class CacheExample {
    static ConnectionMultiplexer redis = ConnectionMultiplexer.Connect("localhost");
    static IDatabase db = redis.GetDatabase();

    public static string GetData(string key) {
        var cached = db.StringGet(key);
        if (cached.HasValue) return cached;

        string data = DBQuery(key);
        db.StringSet(key, data, TimeSpan.FromHours(1));
        return data;
    }

    private static string DBQuery(string key) {
        return $"data_for_{key}";
    }
}

Each illustrates how the application tries Redis first and falls back to the database only on cache miss, reducing expensive queries and improving speed.

Advantages and Disadvantages of Caching

Like how the bakery solved chaos by introducing ticket numbers, caching brings order and speed to data retrieval. Its benefits include:

• Dramatically reducing latency and boosting throughput

• Offloading pressure from databases, keeping them free for critical or unique queries

• Enhancing user experience with consistently fast interactions

But caching isn’t a silver bullet. Challenges include:

• Stale data risks if invalidation rules aren’t handled correctly

• Complexity of cache invalidation — deciding when entries should expire or refresh

• Higher memory costs, since Redis stores everything in RAM

• Over-reliance on masking root issues, making teams ignore database inefficiencies instead of fixing them

Practical Applications

Redis caching powers everyday systems:

• Managing user sessions without constant DB lookups

• Serving e-commerce product catalogs instantly

• Keeping currency exchange rates fresh

• Rate-limiting login attempts to prevent abuse

• Delivering real-time stock market data at lightning speed

Wrapping Up

Just as the Lagos bakery learned to serve more customers efficiently without losing control, system designers rely on caching—especially Redis—to meet user demand at scale while keeping systems responsive.

Caching is one of the core building blocks of scalable architectures, both in interviews and in production. Tomorrow, we’ll dive into event-driven systems with Kafka, another key ingredient in modern distributed designs.