Faster repeated reads

How to use Redis cache in a PHP application

Store an expensive result in Redis for a while. Then keep an eye on keys, lifetime, and removing stale data.

20 minutes · PHP, Symfony, and Redis

First, the short version

When is Redis cache useful?

Redis is a fast in-memory store. It works well as a cache when you read the same data repeatedly and calculating or loading it is expensive.

It is not a second database. The source of truth stays in your database or another service. Cache can disappear at any time, and the application must be able to create the data again.

Get ready

What you need

Before storing anything, decide what you are speeding up and when the data stops being valid.

A running Redis instance reachable from the PHP application. Do not expose it publicly to the internet in production.
A PHP client or Symfony Cache. Choose one approach for the project so keys and rules do not drift apart.
A key name that distinguishes data — for example, product, language, and calculation version.
A rule for lifetime and cache invalidation when source data changes.

Step 1

Add cache gradually

Start with one expensive place. First check that the application works correctly without cache.

1. Connect Symfony to Redis

Install Symfony Cache if the project does not use it yet.
Put the Redis address in an environment variable. Do not commit a password or a full address with a password to the repository.
Configure Redis as the application cache pool and check the connection in a safe environment.

composer require symfony/cache

Symfony Cache and Redis

2. Set a key and lifetime

Name a key after data, not a page. For example: product.42.en.
Choose the lifetime, or TTL, based on how quickly the data changes. It can be short for prices and longer for configuration.
Include everything that changes the result in the key: language, currency, role, or filter.

$item->expiresAfter(300); // 5 minutes

Symfony cache items

3. Delete data when it changes

After changing a product, delete its key. The next visit creates a fresh result.
Do not rely on TTL alone when a user could see an incorrect price or order status for a long time.
Do not clear all Redis on every save. It needlessly throws away cache for everyone else.

$cache->delete('product.42.en');

Symfony cache deletion

Step 2

Check cache hits and stale data

It is not enough that Redis is running. You need to see the application read cache and refresh it correctly after a change.

Check the connection

On the machine where Redis is running, expect a PONG response. Do not run this command through a public endpoint in production.
```
redis-cli ping
```
Read the same data twice

The first read can be a cache miss. The second should use the stored result. Measure time and inspect the application log.
Change source data

Update a product, run cache invalidation, and read the data again. You must see the new value.

If something goes wrong

Common problems

The application reports connection refused

Check the host, port, network path between the application and Redis, and credentials. Do not leave Redis publicly open just to make the connection work.

redis-cli ping

Cache did not make anything faster

Check whether you read the same key repeatedly. A random or overly specific key turns every read into a cache miss.

A user sees an old value

Cache invalidation must run after changing the source. TTL is a safety net, not a replacement for important deletion.

Redis fills up forever

Set a sensible TTL and memory limit, and monitor the number of keys. Do not store large whole responses when you only need a small result.

Done

The cache is under control.

Redis now serves one specific expensive operation, with a clear key, TTL, and a plan for removing stale data.

Read Redis in the glossary All guides