What we build with it
Redis holds the data a service needs immediately and could regenerate if it lost it. Cached query results that would otherwise hit the database on every request, session state, rate-limit counters, short-lived locks, and the job queues that move slow work out of the request path.
That last one is usually the biggest win in a product. Sending an email, generating a document, or calling a third-party API does not belong inside the HTTP request a user is waiting on — pushing it onto a queue is what keeps a page responsive when a downstream service is having a bad day.
Where it fits
In front of PostgreSQL, not instead of it. The pattern we use is boring on purpose: the relational database owns the truth, Redis owns whatever is worth not recomputing, and every key has an expiry so a stale cache is a temporary problem rather than a permanent one.
When we recommend it
When a specific query is measurably hot, when you need background jobs, or when state has to be shared across several instances of a service.
Not as a first move. Adding a cache before you know what is slow buys you a second system to operate and a new class of bug — data that is correct in one place and wrong in another. Measure first, then cache the thing the profile actually points at.
