Redis: Caching and Sessions

Concept

Redis is a database that keeps its data in memory (RAM)instead of on disk. It stores simple values under names, which are called keys. A read or a write usually takes well under a millisecond. That is much faster than a typical PostgreSQL query. One modest server can do tens of thousands of operations per second.

Why your app needs one

After Lessons 8 and 12 you have many servers and one database. As you grow, three problems appear:

People often call Redis the “shared memory of a group of stateless servers”. (Stateless means a server keeps no important data of its own.) It is the last piece that lets the web servers stay disposable, so you can delete and replace any of them.

What Redis actually is

Redis is a key-value store. This means you save a value under a name (the key) and read it back by that name. Redis has several value types, not only strings. Each type has atomic operations. Atomic means the operation happens fully or not at all, and nothing can interrupt it. Every key can also have an expiry time, called a TTL (time to live). When the time ends, Redis deletes the key automatically. This feature makes caches and sessions easy.

• Atomic. Redis runs commands one at a time on a single main thread (one line of work). So INCR counter (add 1 to a number) from a hundred servers at the same moment never loses an update. This is what makes shared counters and locks possible.
• In memory, so size matters. Your data must fit in RAM. A 1 GB node holds roughly a million small cached objects. It cannot hold your whole database.
• Not your system of record. A system of record is the one place that holds the true copy of your data. That place is Postgres. Redis can save data to disk, but you should plan as if any key can disappear at any time. If you lose the cache, the site should become slower, never wrong.

Learn it locally in five minutes

Never learn a new tool on your live system. Run Redis in Docker (Lesson 9) on your own computer and try it out:

SET greeting "hello"            # OK
GET greeting                    # "hello"
SET otp:9876 "482913" EX 60     # a value that deletes itself after 60 seconds
INCR page:views                 # 1, then 2, and so on. Atomic: safe when many servers do it at once
# KEYS *                        # NEVER on a live system: it blocks the server while it scans every key

Redis also has hashes (one key that holds several fields, perfect for a session) and sets (a group of unique members, like “who is online”). It also has a safe way to look through the keys a few at a time, called SCAN. You will meet these in the patterns below. A “pattern” is a common way to solve a problem.

Pattern 1 — caching (cache-aside)

This is the most common use. Your code checks Redis first. If the answer is there (a hit), it returns it at once. If not (a miss), it asks the database, stores the answer in Redis with a TTL, and returns it. The “aside” in the name means the cache sits beside the database, and your code manages both.

import Redis from "ioredis";

// One shared client. In Next.js, keep it on globalThis so hot reload (the dev server reloading code
// when you save) does not open a new connection on every edit.
const g = globalThis as unknown as { redis?: Redis };
export const redis =
  g.redis ??
  new Redis(process.env.REDIS_URL!, {   // rediss://:TOKEN@host:6379 in production (TLS = an encrypted connection)
    maxRetriesPerRequest: 2,
    connectTimeout: 2000,
    commandTimeout: 500,                // a slow cache is worse than no cache, so give up fast
  });
if (process.env.NODE_ENV !== "production") g.redis = redis;

/** Return the cached value, or compute it, cache it, and return it. */
export async function cached<T>(key: string, ttlSeconds: number, load: () => Promise<T>): Promise<T> {
  try {
    const hit = await redis.get(key);
    if (hit !== null) return JSON.parse(hit) as T;
  } catch {
    // Redis is down or slow: FAIL OPEN. This means the site gets slower, but it does not break.
  }

  const value = await load();                       // the slow database query

  try {
    await redis.set(key, JSON.stringify(value), "EX", ttlSeconds);
  } catch {}
  return value;
}

// A dashboard that runs four heavy queries and is requested thousands of times a minute
export async function getDashboard(tenantId: string) {
  return cached(`app:v1:tenant:${tenantId}:dashboard`, 60, () => buildDashboardFromDatabase(tenantId));
}

// When the data changes, remove the old copy at once
export async function updateSettings(tenantId: string, data: Settings) {
  await db.settings.update(tenantId, data);
  await redis.del(`app:v1:tenant:${tenantId}:dashboard`);   // invalidate (remove the old copy) on write
}

The four decisions that make or break a cache

• Key design. Use a clear, structured name such as app:v1:tenant:<id>:thing. In a multi-tenant app (one app that serves many customers), the tenant ID must be in the key. Otherwise one customer can receive another customer's data. That is a serious data leak, not just a bug. The v1 lets you throw away all old entries at once. Change it to v2 after the data format changes.
• TTL. The TTL is the safety net. Even if you forget to remove a key somewhere, old data lives only this long. For data that changes often, use 10 to 60 seconds. For data that changes slowly, use minutes to hours. Always set one.
• Invalidation. Invalidation means removing or updating a cached copy when the real data changes. It is known to be hard. Programmers joke that there are only two hard things in computer science: cache invalidation and naming things. Delete or update the key in the same code that changes the data. Let the TTL clean up the cases you missed.
• What to cache. Cache data that is slow to produce, read often, changes rarely and is the same for many users. Examples are dashboards, product lists, settings and pieces of rendered pages. Do not cache data that is different for every request or very personal.

Pattern 2 — sessions

A session is how the app remembers that a user is logged in across requests. There are two designs, and each has trade-offs:

A signed cookie or JWT (JSON Web Token) is a cookie that holds the login data itself, with a signature so nobody can change it. For a SaaS with admin panels and paying customers, you want to cancel a session at once. That is usually worth one extra millisecond.

The whole Redis-session design is three small functions:

• Create: make 32 random bytes as the session ID, so nobody can guess it. Store userId and tenantId under sess:<id> with a 7-day expiry. Set a cookie that holds only that ID. Give the cookie three flags. httpOnly means JavaScript in the page cannot read it. secure means it is sent only over HTTPS. sameSite: lax reduces CSRF risk. CSRF (cross-site request forgery) is an attack where another website makes your browser send a request that you did not intend.
• Read: look up the key named in the cookie. If it exists, move its expiry forward by another 7 days. This keeps active users logged in.
• Destroy: delete the key. The user is logged out on every server at once. Also keep a set of each user's session IDs. Then “log out everywhere” is just one loop over that set.

Pattern 3 — rate limiting

Rate limiting means capping how many requests one client can make in a period of time. In Lesson 10, Nginx limited each server. With five servers, a client gets five times the allowance. A counter in Redis is shared by all servers. You can also base it on the user or the API key, not only the IP address:

import { redis } from "./cache";

/** Allow `limit` calls per `windowSeconds` for this identity. Returns true if this call is allowed. */
export async function allow(identity: string, limit: number, windowSeconds: number) {
  const window = Math.floor(Date.now() / 1000 / windowSeconds);
  const key = `rl:${identity}:${window}`;

  // MULTI runs INCR and EXPIRE together as one unit, so a key is never left without a TTL if the process dies in between
  const [[, count]] = (await redis.multi().incr(key).expire(key, windowSeconds * 2).exec()) as [
    [null, number],
    [null, number],
  ];
  return count <= limit;
}

// in a route handler:
//   if (!(await allow(`login:${ip}`, 5, 60))) return new Response("Too many attempts", { status: 429 });

The fixed window is simple, but a client can send a burst at the edge between two windows (5 requests at 11:59:59 and 5 more at 12:00:00). If that matters, use a sliding window, which is a sorted set of timestamps. Or use a token-bucket library such as rate-limiter-flexible. Also decide what happens when Redis is down. For a login limiter, many teams fail closed (block the request). For a generous API limiter, they fail open (allow the request).

Patterns 4–6 — locks, queues, pub/sub

4. A lock so only one server does a job

A lock is a marker that says “I am doing this job, so nobody else should”.

// SET key value NX PX 30000  means "set only if the key does not exist, and expire in 30 s". Atomic. Exactly one caller gets OK.
const got = await redis.set("lock:nightly-report", serverId, "PX", 30_000, "NX");
if (got === "OK") {
  try { await runNightlyReport(); }
  finally { await redis.del("lock:nightly-report"); }   // (release it only if you still own it. In real code use a small Lua script, a short program that Redis runs as one atomic step, to check this)
}

This fixes the problem from Lesson 12, where a cron job (a task that runs on a schedule) on every server runs N times. If a second run would cause real harm, as with payments, do not rely on a lock alone. Also make the operation idempotent. Idempotent means that running it twice has the same result as running it once. Locks across many servers are a big topic. Treat this lock as a convenience, not a guarantee.

5. Background job queues

Some jobs should not make a user wait. Examples are sending email, making PDFs and resizing images. The web request puts a job into a queue in Redis and returns at once. A queue is a line of jobs that are handled in order. A separate worker process takes jobs from the queue and runs them. It can retry a failed job or delay a job. In Node the standard tool is BullMQ, which is built on Redis lists and sorted sets. A worker is just another container from your image (Lesson 9) that runs a different command. You can scale workers separately from the web servers.

6. Pub/sub across servers

Pub/sub means publish and subscribe. One part sends messages to a named channel, and every part that has subscribed to the channel receives them. Here is an example. A WebSocket is a connection that stays open so the server and browser can send messages at any time. With WebSockets behind a load balancer, user A may be connected to server 1 and user B to server 2. When A sends a chat message, server 1 PUBLISHes it on a Redis channel. Every server has used SUBSCRIBE, so each one receives the message and sends it to its own connected users. The Redis adapter of Socket.IO (a real-time messaging library) does exactly this.

Memory, eviction and durability

RAM is limited. When Redis reaches its maxmemory setting, the eviction policy decides what happens. Eviction means removing keys to make room:

Durability. Durability means data survives a failure. ElastiCache Multi-AZ with a replica survives the failure of a node. The switch to the replica (the failover) usually takes under a minute. But a replica is asynchronous. This means it copies data a moment after the main node, so the last writes can be lost. That is acceptable for caches, sessions (users just log in again) and rate limits. It is not acceptable for data that exists only in Redis. That is why we said you should not have any such data.

Run it on AWS: ElastiCache

ElastiCache is Redis or Valkey run by AWS. It is a “managed” service, like RDS. AWS does the patching, replaces failed nodes, monitors it and can add replicas. Like the database, it lives in the private subnets. Only the app's Security Group can reach it.

1. The firewall and the subnet group

   A Security Group is a virtual firewall for an AWS resource. It lists which network traffic may come in. Create a security group named cache-sg that accepts port 6379 only from web-sg. Then go to ElastiCache, then Subnet groups, and create one named myapp-private with the two private subnets. This is the same idea as the RDS subnet group in Lesson 8.

2. Create the cluster — with TLS and a password

   Go to ElastiCache and choose Create. Pick Valkey (the open-source copy of Redis that AWS recommends; same commands). Choose a node-based cluster with cluster mode off. Use the myapp-private subnet group and cache-sg. These settings matter most:

   • Replicas: 0 (a single node) is fine for practice and for a small cache. For sessions in production, use 1 replica in another Availability Zone (a separate data centre in the same AWS Region), with Multi-AZ (the replica lives in a different zone) and automatic failover turned on.
   • Encryption in transit: on. This means the traffic between your app and Redis is encrypted with TLS, so the URL starts with rediss:// (two s). Turn it on when you create the cluster. On recent engine versions you can turn it on later, but it takes extra steps and a change on every client, so it is easier to choose it now.
   • Access control: AUTH token. This is a long random password. It must have 16 to 128 printable characters. Besides letters and digits it may use only ! & # $ ^ < > -, so avoid @, /, % and quotes. It adds protection on top of the Security Group. Turn encryption at rest on too. (For teams, ElastiCache also supports users and ACLs. An ACL is an access control list with permissions for each command.)
   • Node type cache.t4g.micro: about 0.5 GB of memory. That is more than enough to start. There is also ElastiCache Serverless. It scales by itself and bills for what you use. For Valkey its minimum is about $6 a month, so it can be cheap for tiny or uneven workloads. A steady, busy cache is often cheaper on a fixed node. Compare the prices for your case.

3. Prove it from the server (not your laptop, because it is private)

   On the EC2 serverCopy all

   • redis-cli -h <REDIS_HOST> --tls -a "$REDIS_TOKEN" pingCopy

     You should see PONG (install redis-tools first). If it hangs, check the security group. If the connection resets, you forgot --tls. If you see NOAUTH or WRONGPASS, check the token

Connect the app safely

Add the URL to the SSM parameter that your servers read (Lesson 12). Then roll out the new setting:

REDIS_URL=rediss://:THE-TOKEN@myapp-cache.abc123.aps1.cache.amazonaws.com:6379

• One client for each process, reused (as in lib/cache.ts). Opening a new connection for every request wastes time and uses up the server's connection limit.
• Short timeouts. A stuck cache must not make your whole site stuck. Use a command timeout of 200 to 500 ms, a short connect timeout and few retries.
• Decide fail open or fail closed for each use. Cache: fail open. Sessions and login: fail closed. Rate limit: your choice, but choose on purpose.
• Never expose it. Give it no public IP and no 0.0.0.0/0 rule. Redis is not built to face the open internet, and exposed instances are often attacked within minutes. To reach it from your laptop, use an SSH tunnel, as you did for the database. An SSH tunnel sends your traffic through an SSH connection to the server.
• Do not run FLUSHALL or KEYS * on your live system. The first deletes every key, including everyone's sessions. The second blocks the server. Use an ACL user for the app that is not allowed to run them.

What to monitor

The hit rate is the share of requests answered from the cache. It tells you whether the cache is worth its cost. A cache with a 20% hit rate costs money and does almost nothing.

When not to use Redis

Every extra part is something you must secure, monitor, pay for and fix at 3 a.m. Do not add Redis only because the diagram looks incomplete:

What this costs

A single micro node costs roughly a fifth of the load-balancer layer, and it can greatly reduce the load on your database. Check the current prices. Valkey costs less than Redis OSS.

Troubleshooting table

Interview corner

Practice task before Lesson 17

1. Run Redis in Docker and work through the redis-cli session above. Watch the TTL count down until a key disappears.
2. Use cached() around one real slow query. Log the hits and misses. Measure the response time with an empty cache (cold) and a full cache (warm).
3. Add the invalidation call to the code that updates that data. Check that users see the change at once.
4. Move sessions to Redis. Log in. Then delete the key in redis-cli. Check that the user is logged out on the next request.
5. Add the rate limiter to your login route. Try six wrong passwords in a minute. Look for the 429 response.
6. Create the ElastiCache cluster. Reach it from EC2 with redis-cli --tls. Then change the app's REDIS_URL and roll out.
7. Stop Redis (or block the port) and load the site. It must still work, only more slowly. If it crashes, fix the fail-open handling.

Conclusion

Redis is the shared, very fast whiteboard for a group of disposable servers. It holds cached answers, sessions, counters, locks and short queues. It should never hold the only copy of anything you would miss.

• Cache-aside with structured keys that include the tenant, a TTL on everything, invalidation when data is written, and fail-open behaviour.
• Sessions in Redis can be cancelled at once. They must fail closed, and in production they need a replica.
• Shared counters make rate limits work across all servers.
• Match the eviction policy to the job. Caches evict, queues do not. Do not mix them.
• Keep it private, with TLS and AUTH. Add it only when measurements show that you need it.

The system now has all its features. But how do you know it is healthy right now? How will you find out at 3 a.m. that it is not? That is monitoring.

End of Lesson 16. Next: Lesson 17 — Monitoring and Logging with CloudWatch.