Glossary

Redis: fast in-memory data for application work

Caches, sessions, counters, and coordination can be fast—but only when the system can handle expiration, outages, and invalid data.

Short definition

Fast storage for temporary and operational state.

Redis does not primarily work with tables and SQL. It stores values under keys and provides operations on strings, hashes, lists, sets, sorted sets, and other structures. Many basic operations on a single key are atomic, which is useful for cases such as a request counter.

Data resides primarily in RAM. Redis supports disk persistence, replication, and other operational modes, but these do not remove the need to identify the source of truth. For orders and irreplaceable records, that is usually a relational database; Redis provides a derived, short-lived, or coordination layer.

Use cases

Where fast data helps

A use case should reflect whether the data can be recomputed, how long it remains valid, and what happens during an outage.

caching products, configuration, and expensive queries
session storage for multiple application instances
counters, quotas, and API rate limiting
short-lived tokens and results of ongoing operations
queues and streams with consumer-group processing
coordination and distributed locks between workers

Practical example

Product catalogue cache

An online store looks for a product under the key product:4821:detail. On a cache miss, it loads the product from the relational database, stores the serialised result with a short TTL, and returns the response to the visitor.

When the price or inventory changes, the application invalidates the cache directly or writes the new content. TTL is a safety net, not a consistency mechanism: without invalidation, users can see stale state until expiration. During a Redis outage, the application reads the source of truth, even at the cost of higher database load.

How it works

Cache-aside: key, TTL, and fallback

The most common caching pattern shows where the application’s responsibility begins.

Request The backend needs a product or another value that remains valid for a short time.
Reading the key It reads a predictably named key from Redis.
Fallback On a cache miss or outage, it loads the authoritative database or service.
Writing with TTL It stores the result for a limited time, after which the key expires.
Invalidation A change to the source of truth deletes or refreshes the corresponding keys, and the team monitors operational metrics.

Important features

Data structures, expiration, and shared state

Choose a structure according to the operation the application needs to perform.

Data structures

A string suits a simple value or counter; a hash stores multiple properties, a set holds unique members, a sorted set maintains ordering, and a stream stores records processed by a group.

TTL and cache

After TTL expires, Redis treats the key as expired when read and removes it over time. TTL suits a cache, quota, or one-time token—not the only copy of important data. Cache-aside still requires invalidation after a write.

Sessions and rate limiting

Shared sessions make it easier to run multiple PHP instances. Atomic increments and expiration help count request limits; the exact time-window algorithm remains a design decision.

Pub/Sub, Streams, and locks

Pub/Sub delivers a message only to subscribers connected at that moment; it is lost on disconnection. Streams retain records for groups and offer a different processing model. A lock limits concurrency, but none of these features alone guarantees an idempotent business effect.

Benefits and limitations

Speed does not replace data design

Benefits

fast operations on frequently read, short-lived data
TTL and atomic commands for caching, counters, and coordination
shared temporary state for multiple application instances
complementing a relational database instead of trying to replace it everywhere

What to watch for

TTL alone does not solve invalidation and can return stale values
a cache outage must not cause an application outage or a database stampede
uncontrolled key growth can exhaust memory
a Redis lock does not guarantee exactly-once behaviour or replace database protection

Scope of use

Redis helps when speed and lifetime match the data.

It is suitable for caching, short-lived state, sessions, quotas, and coordination where losing a key does not destroy an authoritative business record. It also fits when multiple application instances need to share the same temporary state.

For complex relational queries, long-term history, and an accounting trail, speed is not a reason to replace a relational database. Before deployment, identify the specific bottleneck and the plan for Redis being unavailable.

What to keep in mind

Redis needs limits, measurement, and fallback

Operational safety depends on rules around both the server and application.

key prefixes and TTLs appropriate to the nature of the data
a maxmemory and eviction policy appropriate to the risk of loss
monitoring memory, evictions, latency, connections, and cache hit rate
testing an outage, restart, and simultaneous cache misses
network security, ACLs, and no sensitive data in keys

Common questions

What Redis does and does not solve

Is Redis a database or a cache?

Technically, it is a data store with its own structures and persistence. In many applications it serves primarily as a cache; what matters is whether the design can tolerate losing it.

Why isn’t a long TTL enough?

A long TTL reduces the number of queries but extends the period during which the application can return stale data. It is a trade-off complemented by invalidation when important data changes.

Can Redis replace PostgreSQL?

It can be the authoritative store for a simple use case, but its data model, querying, and operational properties differ. A relational database is usually more suitable for orders and long-term history.

Does a Redis lock ensure a job runs only once?

Not completely. A lock limits concurrency, but uncertainty remains after a timeout, process crash, or failover. The job result should be idempotent or also protected in the authoritative store.

How I use Redis in practice

I use Redis where fast, short-lived state makes sense.

In integration services, I design caching, coordination, and operational limits around the specific data flow.

How I use Redis in practice Discuss your project without obligation