PHP Cache Invalidation Without Stale Data

PHP cache invalidation is not about choosing a TTL and storing responses in Redis. It is a consistency decision: determining which information may be delayed, for how long, and what must happen when the original data changes. A poorly designed cache can show an old price, grant access using revoked permissions, or display availability that no longer exists. An overly conservative cache, on the other hand, shifts all the load to the database and loses its purpose.

The starting point is to treat every entry as data with a defined owner, lifecycle, and risk. This allows product, business, and technology teams to agree on when a potentially stale read is acceptable and when the current state must be obtained from the source of truth.

Classify data before caching it

Not all frequently accessed data should be cached, nor does all data support the same mechanism. Evaluate each read using four criteria: volatility, the impact of staleness, the cost of querying the source, and tolerance for a cache failure.

• Low volatility and low impact: public catalogs, metadata, or non-sensitive settings can usually support TTLs of minutes or hours, depending on their change process.
• Medium volatility: product details, dashboard aggregates, and search results can be cached if they are invalidated when the records that compose them change.
• High impact: permissions, balances, limits, transactional states, inventory during purchase confirmation, and authorization controls require a consistent source of truth or an explicit, very strict freshness strategy.
• Expensive-to-compute data: reports and derived summaries can justify caching even if they are not accessed often, but they must declare which entities invalidate them.

It is useful to separate presentation caching from decision caching. Displaying a category's former name for a few seconds may be acceptable. Using an old policy to authorize an operation normally is not. For critical decisions, query the authoritative source or store versions that can be verified before acting.

Define ownership, keys, and freshness contracts

Each entry needs an operational record. It must indicate the source of truth, the key, consumers, maximum TTL, invalidation event, behavior if Redis is unavailable, and the functional or technical owner. Without this contract, keys multiply and nobody knows what to remove after a change.

Use predictable keys with sufficient scope. For example, product:42 represents a specific entity; tenant:8:product:42 prevents data from being mixed between organizations; and dashboard:tenant:8:period:current identifies a derived result. Do not include secrets in keys or use unstable serializations as identity.

It is also advisable to maintain a consistent value format: payload, version or generation date, and, when relevant, a freshness indicator. A consumer should not assume that a cached response is equivalent to a transactionally consistent read.

final class ProductCacheKey
{
    public static function detail(int $tenantId, int $productId): string
    {
        return "tenant:{$tenantId}:product:{$productId}:v1";
    }
}

The schema suffix makes it possible to change the value structure without having to locate and remove every historical entry. It does not replace invalidation of business data, but it reduces risk during a format evolution.

Choose the update pattern according to the type of read

Cache-aside for reusable reads

With cache-aside, the application looks up the key first; on a miss, it queries the database, builds the value, and stores it with a TTL. It is simple and suitable for relatively stable reads. Its limitation is clear: after a write, someone must remove or replace the affected entries.

Invalidation must occur after the transaction is committed. Deleting before commit can cause another process to rebuild the cache with the still-old value. If the application publishes events, an outbox pattern helps record the change in the same transaction and reliably deliver the invalidation command afterward.

Explicit updates and versioning

If an entity is read very frequently and its changes are controlled, the entry can be updated after the write is committed. This avoids the next cache miss. However, the process must generate exactly the same representation readers expect; otherwise, invalidating and rebuilding is usually less risky.

Key versioning is useful for broad dependencies. Instead of deleting all product lists for an organization, increment tenant:8:products:version and have lists include that number in their key. Old lists expire on their own. This approach reduces mass deletions, but requires controlling key growth and should not be used to hide a poorly understood dependency.

Control race conditions and derived dependencies

The typical race occurs as follows: a read misses the cache and queries the old value; a write commits and invalidates; the first read finishes and stores the old value again. For sensitive data, combine invalidation with entity versioning or a short rebuild lock. Before storing the computed value, verify that the version queried is still current. If it is not, discard the result and read again.

Distributed locks must be short, have an expiration, and not become a single blocking point. Their purpose is to reduce simultaneous rebuilds, not to ensure business consistency on their own. If the lock is not acquired, one option is to wait briefly for the rebuilt value or allow a limited direct read.

Dependency invalidation requires an inventory. A product change can affect its details, several lists, search results, counters, and a dashboard. A role change can affect users' effective permissions and derived menus. Model these relationships explicitly:

• Invalidate the direct entity through its key.
• Invalidate or version the collections and aggregates that depend on it.
• Recalculate expensive results asynchronously if the experience allows it.
• Do not confuse clearing a view with updating the source of truth.

When the relationship is not easily enumerable, a version namespace by organization, catalog, or policy is usually safer than attempting to discover every affected key through global deletion patterns.

Use TTL, jitter, and limits to protect the source

TTL is a safety net, not the only consistency mechanism. Even a correctly invalidated key must expire: event delivery failures, deployment errors, or orphaned entries may exist. Choose TTLs based on the cost of the error, not only on the cost of the query.

Apply random jitter to the TTL so that thousands of keys created at the same time do not expire simultaneously. Also, protect the source against a cache-miss avalanche through per-key rebuild locking, concurrency limits, and per-consumer quotas. For non-critical data, a slightly expired value can be served while a single process recalculates it; for permissions or decision-making availability, this technique must be discarded or limited to explicitly approved scenarios.

Design degradation for when Redis fails

Redis is an operational dependency, not the source of truth. If it does not respond, the application needs a defined degradation mode. For an inexpensive public read, it can query the database directly with time limits. For expensive queries, it is advisable to apply load shedding, reduce fields, respond with a temporarily unavailable status, or use an appropriate replica if the architecture provides for one.

Do not turn a cache failure into database connection exhaustion. Define short timeouts, circuit breakers, query budgets, and metrics by route. For critical data, it is preferable to reject an operation rather than make a decision using permissions, balances, or inventory whose freshness cannot be guaranteed.

Test and observe freshness, not just hits

A high hit rate does not prove that the cache is correct. Instrument hits, misses, latency, read and write errors, remaining TTL, rebuild locks, issued and failed invalidations, as well as database queries and saturation. Associate these signals with each key family, not only with Redis as a global service.

In tests, cover at least the initial read, subsequent update, deletion, post-commit invalidation, cache failure, and races between reader and writer. Verify that a user loses access after a permission is revoked, that a list reflects a change according to its freshness contract, and that a failed invalidation triggers alerts or recovery.

Checklist for an existing PHP application

1. List repeated reads and classify them by risk, volatility, and cost.
2. Declare the source of truth and the maximum staleness tolerance for each piece of data.
3. Document keys, TTLs, dependencies, consumers, and the invalidation event.
4. Run invalidations or updates only after the commit is confirmed.
5. Protect against simultaneous rebuilds and add jitter to relevant expirations.
6. Define the degraded mode for Redis unavailability without overloading the database.
7. Measure freshness and invalidations, not only the hit rate.
8. Periodically review ownerless keys, excessive TTLs, and uncovered dependencies.

A reliable PHP cache invalidation strategy makes its trade-offs visible: what can become stale, for what interval, how it is corrected, and what happens when a component fails. That clarity is more valuable than adding a cache indiscriminately.