What Redis Is Used For
Wordcraft's profile page runs three joins in PostgreSQL and takes 80 milliseconds. Thousands of players open it every minute, and almost nobody's profile changes in that time. Doing the same slow work again and again is the kind of waste Redis is usually hired to remove, and caching is only the first of its jobs.
The rule
Small, hot, fast-changing data goes to Redis.
Every common use of Redis has the same shape: many tiny reads or writes that must be quick. The usual jobs:
- Cache. Keep the result of slow work (a query, an API call, a rendered page) under a key with an expiry. Read Redis first; only on a miss do the slow work and store the result.
- Session store. A logged-in player's session is a key such as
session:9f2cwith a lifetime. Every request checks it, and Redis deletes it on its own when it expires. - Counters and rate limits.
INCRadds one safely even when many servers count at once: page views, games played, login attempts per minute. - Leaderboards. A sorted set keeps members ordered by score, so "top ten" or "my rank" is one command.
- Message broker. With publish/subscribe (pub/sub), one client publishes a message to a channel and every client listening on it receives it at once, which suits live chat and notifications. Lists and streams can also act as job queues between services.
- Real-time analytics. Counters, sets of unique visitors and time-bucketed keys give numbers that update as events happen, not in tomorrow's report.
Here is the cache pattern for the profile page:
GET cache:profile:asha # (nil) on the first visit: a miss
SET cache:profile:asha "{...}" EX 60
GET cache:profile:asha # "{...}" for the next 60 seconds: a hitEX 60 gives the key a 60-second lifetime, so a stale copy cleans itself up.
The shortcut
To decide whether a job suits Redis, ask three quick questions: Is each piece small? Is it read or written very often? Does it have a natural lifetime or a live order? Two or three yeses point to Redis.
Small?
Yes: it is a single number.
The trap is treating Redis as the only copy of important records such as purchases. Those belong in the main database; Redis holds the fast, often rebuildable layer on top.
Drills
Answer fast — trust the rule.
A cache read returns (nil). What should the app do next?
Which feature makes Redis a good session store?
Which job is pub/sub built for?
Which Wordcraft data should NOT live only in Redis?
Remember
- Small, hot, fast-changing data goes to Redis.
- Small? Very often? Lifetime or live order? Two or three yeses point to Redis.
- Redis is the fast layer, not the only home for records you cannot lose.