Key-Value Stores and Caches

This is the simplest database family in the whole book: a key, a value, and nothing else. You say "put this value under this name", and later you say "give me what's under that name". No tables, no relationships, no queries beyond that one — and because it does so little, it does it blindingly fast. Redis is the household name.

That narrowness sounds like a weakness until you meet the job it was born for: the cache, a fast memory layer that sits in front of the real database and answers the same question a thousand times without bothering it. And it turns out the Marquee's homepage needs exactly that.

The Whole Model in One Breath

Two operations cover it. SET stores a value under a key; GET hands it back. That's the entire vocabulary. Crucially, the store treats the value as an opaque blob — it never looks inside. To Redis, the value is a sealed parcel: it holds the parcel under the name you gave, returns it when asked, and has no idea and no opinion about what's in it.

Think of a coat check at a theater. You hand over your coat, you get a numbered tag, and later the tag gets your coat back. The attendant never opens the coat, never sorts by color, never answers "which coats have a phone in the pocket?" — and that refusal to look inside is exactly why the line moves fast. A key-value store is that coat check for data.

Why It's So Fast

Two reasons, both from doing less. First, the data usually lives in memory rather than on disk, and memory is thousands of times faster to reach. Second, the operation is a single direct lookup — no planner deciding how to run it, no rules to check, no locks to negotiate. You asked for one named thing; it hands you the one named thing.

The honest cost of living in memory: if the machine restarts, memory is wiped, so a pure in-memory store can lose what it held. Redis can be configured to save to disk and soften that, but the family's instinct is speed first, permanence second — which is fine, because its main job holds nothing it can't rebuild.

The Cache Pattern

Here's the Marquee's problem. The homepage shows "tonight's screenings", and that list comes from the query Chapter 8 made fast — a real query, but still real work, and it runs identically for every single visitor. A thousand people load the homepage in an hour and the database answers the exact same question a thousand times. Wasteful.

The cache fixes it. The first visitor's request runs the query, and the application stores the result in Redis under a key, with a lifetime attached:

SET screenings:tonight  "…the rendered list…"  EX 60
GET screenings:tonight

The EX 60 says "keep this for 60 seconds, then forget it". For the next minute, every visitor's homepage is served straight from that key — a coat-check lookup, no database work at all. After 60 seconds the key expires, the next visitor's request runs the query once more, and the cycle repeats. The database answers roughly once a minute instead of once a click.

That 60 seconds of staleness is chosen on purpose. It's the fridge whiteboard from Chapter 6 all over again — a fast running total kept beside the true source, accepted as slightly behind because glancing at it is so much cheaper than re-counting. Here the whiteboard has a 60-second timer built in, and the true source, the relational database, stays the truth.

What It Refuses to Do

The coat check's refusal to look inside is also its wall. A key-value store cannot answer "which keys hold a screening on screen 1?" — it never looks inside the parcels. No relationships, no constraints, no querying by content. If your question is anything other than "the value under this exact key", you have reached for the wrong tool, and that's not a flaw — it's the deal you signed for the speed.

Within that deal, the family has other day jobs beyond caching: holding login sessions, counting things at high speed, passing short messages between parts of a system. All the same shape — a name, a value, gone in and straight back out.