TTL, Sessions & Caching Patterns

In this chapter

We'll meet TTL and expiration for real, build a session that expires on its own, and tell apart cache-aside, write-through, and write-behind as genuinely different strategies.

9–11 min

The Problem in Real Life

A shopper adds three items to their cart, gets distracted, and never comes back. Their cart — and the session that remembers who they were — just sits in Redis's memory, forever, unless something eventually clears it out. Multiply that by every shopper who's ever half-finished a visit, and GreenMart's fast, in-memory store quietly fills up with things nobody's coming back for.

Sarah needs Redis to remember things — but not remember them forever.

It's not that I want it gone right away. I want it gone eventually, on its own.

Sarah

Remembering Forever vs. Remembering On Purpose

TTL removes a key automatically

No cleanup job needed — Redis removes an expired key on its own, exactly when its TTL runs out.

Sessions fit a Hash plus a TTL

Several related fields under one key, gone automatically after a period of inactivity.

Three genuinely different caching patterns

Cache-aside, write-through, and write-behind trade off freshness, write cost, and complexity differently.

Invalidation is the same problem underneath

How does Redis find out its copy is stale — a TTL that eventually expires, or an explicit delete on update?

TTL — time to live — is exactly the fix: a number of seconds after which a key expires and Redis removes it automatically, with nothing else having to notice or clean up after it.

A session is a natural fit for a Hash (several related fields under one key) plus a TTL — 1800 seconds, thirty minutes of inactivity, after which the session simply stops existing. No cleanup job, no scheduled sweep — Redis handles the removal itself, exactly when the TTL runs out.

A Session That Expires On Its Own

HSET session:tok-88a1 userId "u-501" cartId "cart:1042"
EXPIRE session:tok-88a1 1800
TTL session:tok-88a1

TTL is the mechanism. Caching patterns are the actual strategies for deciding when data goes into Redis and when it comes back out, and they're worth telling apart precisely, since they trade off differently:

Cache-aside (the most common shape, and the one that fixed this Act's own flash sale): the application checks Redis first; on a miss, it reads the real database, then writes that result into Redis before returning it. Redis only ever holds what's actually been asked for.

Write-through: every write goes to Redis and the real database together, at the same time, before the write is considered done. Reads are always fresh, at the cost of every write paying for both stores.

Write-behind (write-back): a write lands in Redis immediately and returns right away; the real database gets updated afterward, asynchronously. Fast writes, at the cost of a real window where Redis and the database disagree.

Whichever pattern is in play, cache invalidation is the same recurring problem underneath: how does Redis find out its copy is stale? TTL is one honest answer — a cached value expires and gets refreshed the next time it's asked for, correct again within one request, no explicit signal required. The other is explicit: an update to the real data actively deletes (or overwrites) the matching Redis key at the same moment, rather than waiting for a TTL to eventually catch up.

Key Takeaway

TTL is the mechanism — a key that removes itself. Cache-aside, write-through, and write-behind are the actual decisions about when data enters Redis and how invalidation gets handled, and they trade off differently.

Why This Matters

Every cached value or session this Act builds from here on assumes a TTL is part of the design, not an afterthought bolted on later. The next chapter's atomic counters and locks need the exact same expiring-key idea — a lock that never expires on its own is a real, common way distributed locking breaks in production.

GreenMart's Redis usage now remembers things on purpose, not by accident forever. The flash sale's real danger hasn't shown up yet, though — two customers reaching for the exact same last unit, at the exact same instant.