Redis and caching: how to invalidate data without showing outdated information
Published on 2026-10-26 by frfrand
TTL, keys and cache invalidation patterns when caching APIs
You added Redis and your API now responds in milliseconds. Perfect, until a user changes their reservation and keeps seeing the previous time slot. Speeding up data is easy; keeping it up to date is what requires design.
The idea is to solve a data or deployment problem that appears in real applications. We will look at the concept without fluff, an implementation example, and what to check before taking it to production.
What Redis cache invalidation does
Redis can store keys with TTL and serve repeated reads. Invalidation consists of deciding when each piece of data expires or is deleted when the primary source changes. The pattern depends on whether you accept temporarily stale data and on how many processes can write.
Simply repeating a recipe is not enough if you don't understand who reads the data, from which process, and with what permissions. In an application with reservations, invoices, or users, a race condition or a poorly implemented access policy can be more serious than a slow API.
A concrete example
# Ejemplo desde redis-cli en entorno de prueba
SET horarios:42 '{"plazas":3}' EX 60
GET horarios:42
TTL horarios:42
DEL horarios:42
# Usar prefijos claros y evitar borrar claves de otras appsThe names, tables, and keys in this example are illustrative. Try it first in a test or staging environment and adapt permissions, indexes, and versions. When there are write operations, do not run sample queries on customer data without reviewing what they modify.
Step by step
- Choose only repeated reads that truly justify caching.
- Define key structure by entity and, if there are multiple clients, by tenant.
- Assign TTL according to the risk of showing outdated information.
- When modifying PostgreSQL, invalidate affected keys after confirming the transaction.
- Measure hit rate and verify consistency with concurrent change tests.
In the end, do not settle for "the SQL did not return an error". Verify the actual effect from the API and with concurrency or permission tests as appropriate. In databases there are errors that only appear when two users do something at the same time.
Example work project
The public tours page shows schedules and available spots. You can cache the list for a few seconds, but when confirming a reservation you must always check availability in PostgreSQL under transactional control.
That scenario helps distinguish performance from consistency. Speeding up a query is useless if it allows creating two reservations for a single spot, nor does a huge database fix the backend allowing querying another client's data.
The typical error
Do not use cache as the definitive source for payments or spots without consistency mechanisms. FLUSHALL on a shared Redis can affect other projects; manage namespaces and databases carefully.
It's also a good idea to have a recovery plan. Before touching schemas, users, or policies, save a verifiable copy or reversible migration and check that the application can keep working during the change.
How would I solve this with ArduMaker?
ArduMaker can host Redis alongside PostgreSQL and an API on a VPS. Define memory limits and access protection; Redis without authentication or a restricted network is not a good idea.
ArduMaker allows you to deploy services from Git and work with databases and processes within the VPS. The panel does not replace your application's logic: transactions, permissions, and validations must be properly designed in the code and the database.
Three checks before publishing
Integrity: if a request is repeated or fails halfway through, do the data end up in a valid state?
Security: can an authenticated user access only their own information, and does the API use a base identity with minimal permissions?
Recovery: do you know how to restore the data and revert the compatible code version if an update goes wrong?
If you can answer those three questions with tests, your backend is much better prepared than when you only checked if the endpoint returned 200.
Resources to learn more
To wrap up: choose the simplest solution that allows you to keep data correct, secure, and recoverable. Performance comes after measuring.