What Is Redis? The Complete Guide for AI-Assisted Developers

Why AI Coders Need to Know This

Redis is the world's most popular in-memory database, used by companies including Twitter, GitHub, Stack Overflow, and Airbnb. In the AI coding ecosystem, it appears whenever a project reaches performance limits or needs features that a regular database handles poorly.

Common scenarios where AI adds Redis:

• Rate limiting: "Limit users to 100 API calls per hour" — Redis tracks request counts atomically
• Session storage: "Store user sessions server-side" — Redis with TTL auto-expires old sessions
• Caching: "The database query for the homepage takes 2 seconds" — cache the result in Redis for 5 minutes
• Job queues: "Process image uploads in the background" — BullMQ uses Redis as its queue backend
• Real-time features: "Show live visitor counts" — Redis pub/sub for instant updates

Understanding Redis makes you able to evaluate whether an AI-suggested caching strategy is appropriate, debug cache invalidation bugs, and understand why some "database" calls in AI-generated code return in microseconds while others take milliseconds.

The Core Idea: RAM Is Faster Than Disk

Your primary database (PostgreSQL, MongoDB) stores data on disk. Disk access takes ~5 milliseconds. Redis stores data in RAM. RAM access takes ~0.1 milliseconds — about 50x faster. For frequently accessed data, this difference is enormous at scale.

Redis is not a replacement for your database — it is a complement. The standard pattern: use PostgreSQL as the source of truth, Redis as a fast read layer in front of it.

Real Scenario

Your Next.js app fetches a product catalog on every page load. The database query joins 3 tables and takes 800ms. With 100 users per minute, that is 100 queries × 800ms = your database is struggling. You ask Cursor to add Redis caching.

Add Redis caching to my product catalog API:
- Cache the result of GET /api/products for 5 minutes
- Invalidate the cache when a product is created, updated, or deleted
- Use Upstash Redis (serverless-compatible)
- Show me the cache-aside pattern with proper error handling
- What should I do if Redis is unavailable?

What AI Generated

// lib/redis.ts — Redis client setup (Upstash for serverless)
import { Redis } from '@upstash/redis';

export const redis = new Redis({
  url: process.env.UPSTASH_REDIS_REST_URL!,
  token: process.env.UPSTASH_REDIS_REST_TOKEN!,
});

// app/api/products/route.ts — cached API route
import { redis } from '@/lib/redis';
import { prisma } from '@/lib/prisma';

const CACHE_KEY = 'products:all';
const CACHE_TTL = 300; // 5 minutes in seconds

export async function GET() {
  try {
    // 1. Try Redis first (cache hit)
    const cached = await redis.get(CACHE_KEY);
    if (cached) {
      return Response.json(cached, {
        headers: { 'X-Cache': 'HIT' }
      });
    }

    // 2. Cache miss — query database
    const products = await prisma.product.findMany({
      include: { category: true },
      orderBy: { createdAt: 'desc' }
    });

    // 3. Store in Redis with TTL
    await redis.setex(CACHE_KEY, CACHE_TTL, JSON.stringify(products));

    return Response.json(products, {
      headers: { 'X-Cache': 'MISS' }
    });

  } catch (error) {
    // 4. Redis failure — fall back to database (graceful degradation)
    console.error('Cache error, falling back to DB:', error);
    const products = await prisma.product.findMany({
      include: { category: true }
    });
    return Response.json(products);
  }
}

// Cache invalidation on mutations
export async function POST(req: Request) {
  const data = await req.json();
  const product = await prisma.product.create({ data });

  // Delete cache so next request fetches fresh data
  await redis.del(CACHE_KEY);

  return Response.json(product, { status: 201 });
}

Understanding Each Part

Keys and values

Redis stores data as key-value pairs. The key is a string identifier. The value can be a string, number, JSON, list, set, or hash. In the example, products:all is the key and the serialized JSON array of products is the value. Key naming conventions (using colons as separators) help organize a large Redis keyspace.

TTL (Time to Live)

SETEX key seconds value stores a value with an expiration. After the TTL, Redis automatically deletes the key. This is how caches stay fresh without manual cleanup. Common TTLs:

• 60 seconds: Dynamic data that changes frequently (live counts, trending items)
• 300-600 seconds (5-10 min): Semi-static data (product listings, user profiles)
• 3600 seconds (1 hour): Mostly static data (configuration, category lists)
• 86400 seconds (1 day): Rarely changes (feature flags, static reference data)

The cache-aside pattern

The code above uses "cache-aside" — the most common caching pattern:

1. Check Redis first (is the data cached?)
2. If cache hit: return the cached value immediately
3. If cache miss: fetch from the database, store in Redis, return the value
4. On mutations: delete (invalidate) the cached key so the next read gets fresh data

Graceful degradation

The try/catch wrapper around Redis operations is critical. Redis should be an enhancement, not a dependency. If Redis is down, the app should still work — just slower. AI sometimes generates code where a Redis failure crashes the whole request.

Common Redis data structures

// String — simple key-value
await redis.set('user:123:name', 'Chuck');
await redis.get('user:123:name'); // 'Chuck'

// Hash — like an object (avoid redundant serialization)
await redis.hset('user:123', { name: 'Chuck', plan: 'pro' });
await redis.hget('user:123', 'plan'); // 'pro'

// Sorted Set — leaderboard / rate limiting
await redis.zadd('leaderboard', { score: 1500, member: 'chuck' });
await redis.zrevrange('leaderboard', 0, 9); // Top 10

// Increment — atomic counter (rate limiting)
const count = await redis.incr('rate:user:123:minute');
if (count > 60) return res.status(429).json({ error: 'Too many requests' });
await redis.expire('rate:user:123:minute', 60);

What AI Gets Wrong About Redis

No graceful degradation

AI generates Redis calls without error handling. When Redis is unavailable during deployment, maintenance, or a network blip, the app crashes instead of falling back to the database. Always wrap Redis operations in try/catch.

Cache invalidation gaps

AI caches a resource on GET but forgets to invalidate on PUT, PATCH, and DELETE. Users see stale data after updates. Map out every mutation endpoint and ensure each one clears the relevant cache keys.

Caching user-specific data under shared keys

// ❌ Bug — all users share the same cache key
await redis.set('current_user', JSON.stringify(user));

// ✅ Include user ID in the key
await redis.setex(`user:${userId}:profile`, 300, JSON.stringify(user));

Using Redis as a primary database

AI sometimes stores application data exclusively in Redis without a durable database. Redis can lose data on restart if persistence is not configured. Always use Redis alongside a durable database, not instead of one.

Connection pool issues in serverless

Traditional Redis clients maintain persistent connections. In serverless functions (Vercel, Lambda), each invocation may create a new connection, exhausting Redis's connection limit fast. Use Upstash (HTTP-based, no persistent connections) or the connection reuse pattern for serverless deployments.

What to Learn Next

• What Is a Database? — Understand the primary database Redis sits in front of.
• What Is Rate Limiting? — Redis is the standard backend for API rate limiting.
• What Are Environment Variables? — Redis connection strings need secure environment configuration.
• What Is an API? — Caching is most valuable at the API layer.

FAQ