Estratégias de invalidação de cache
Aprenda a manter os dados em cache atualizados e consistentes usando TTLs, gravação simultânea, gravação posterior e invalidação orientada a eventos no Redis.
Estratégias de invalidação de cache é uma aula grátis de Redis Caching & Messaging (Pub/Sub, Streams) no CoddyKit. Esta é a aula 4 de 4. Você pode ler a aula completa abaixo gratuitamente — depois pratica ao vivo no navegador com um editor de código integrado e um tutor de IA 24/7. Faz parte do caminho de aprendizado de Redis Caching & Messaging (Pub/Sub, Streams), e seu progresso é sincronizado entre a web e o app CoddyKit. O curso de Redis Caching & Messaging (Pub/Sub, Streams) inclui 4 aulas no total.
Partes desta aula ainda não foram traduzidas e aparecem em inglês.
Why Invalidation Matters
Caching speeds up reads, but a cache that serves stale data can be worse than no cache at all. Cache invalidation is the discipline of removing or refreshing entries when the underlying source of truth changes.
It is famously hard: there are only two hard things in computer science, and one of them is cache invalidation.
TTL-Based Expiry
The simplest strategy is time-to-live. You accept that data may be stale for at most N seconds.
SET key value EX 60expires after 60 secondsEXPIRE key 60sets a TTL on an existing keyTTL keyshows remaining seconds
SET user:42:profile "...json..." EX 60
TTL user:42:profile
EXPIRE user:42:profile 120Write-Through Caching
In write-through caching, every write goes to both the database and the cache in the same operation. Reads are always fresh, at the cost of slower writes.
The application is responsible for keeping the two in lockstep.
def save_user(user):
db.update(user)
redis.set('user:' + user.id, serialize(user))
return userWrite-Behind Caching
Write-behind (write-back) writes to the cache first and flushes to the database asynchronously. Writes are fast, but you risk data loss if Redis goes down before the flush.
Use a queue or stream to buffer pending writes.
redis.set('order:' + id, data)
redis.lpush('pending_writes', id)Explicit Deletion on Update
The cache-aside + delete pattern: on every update to the database, delete the cached key. The next read repopulates it.
This avoids serving stale data and is simpler than keeping the cache value in sync.
def update_product(p):
db.update(p)
redis.delete('product:' + p.id)Why Delete Beats Update
Deleting the key (instead of overwriting it) avoids a race condition: two concurrent updates could otherwise write values in the wrong order. With deletion, the next read always pulls the latest from the source of truth.
Versioned Keys
Instead of invalidating, bump a version number embedded in the key. Old keys expire naturally via TTL while new reads use the new key.
INCR config:version
GET config:version
SET config:v7:settings "..."Event-Driven Invalidation
Publish an invalidation event whenever data changes. Other application nodes subscribe and clear their local caches. This pairs Redis Pub/Sub with caching.
redis.publish('invalidate', 'user:42')
# subscribers:
redis.subscribe('invalidate')Tag-Based Invalidation
Group related keys under a tag set. When a tag becomes invalid, delete all member keys in one sweep.
SADD tag:user:42 product:1 product:2- On change:
SMEMBERS tag:user:42thenDELeach
SADD tag:user:42 cart:42 wishlist:42
SMEMBERS tag:user:42Avoiding Stampedes
When a hot key expires, many requests may hit the database at once (a cache stampede). Mitigate with a short lock, probabilistic early expiry, or serving slightly stale data while one worker refreshes.
SET lock:user:42 1 NX EX 5Choosing a Strategy
There is no single best approach:
- TTL for tolerable staleness
- Delete-on-write for correctness
- Event-driven for multi-node consistency
- Versioning for bulk config changes
Quick Check
Test your understanding of invalidation strategies.
Recap
You learned the major cache invalidation strategies: TTL expiry, write-through, write-behind, delete-on-write, versioned keys, event-driven, and tag-based invalidation, plus how to avoid cache stampedes. Pick the strategy that matches your tolerance for staleness and your consistency needs.
Perguntas Frequentes
A aula “Estratégias de invalidação de cache” é grátis?
Sim — o texto completo de “Estratégias de invalidação de cache” é grátis para ler aqui na web. Para praticá-la interativamente (um editor de código integrado e um tutor de IA 24/7) e desbloquear o restante do curso de Redis Caching & Messaging (Pub/Sub, Streams), atualize para CoddyKit PRO. O curso de Redis Caching & Messaging (Pub/Sub, Streams) inclui 4 aulas no total.
O que vou aprender em “Estratégias de invalidação de cache”?
Aprenda a manter os dados em cache atualizados e consistentes usando TTLs, gravação simultânea, gravação posterior e invalidação orientada a eventos no Redis. Você pratica Redis Caching & Messaging (Pub/Sub, Streams) com código prático que executa diretamente no navegador, e um tutor de IA 24/7 responde suas dúvidas enquanto trabalha na aula.
Preciso ter experiência prévia para começar Redis Caching & Messaging (Pub/Sub, Streams)?
Nenhuma experiência prévia é necessária. Redis Caching & Messaging (Pub/Sub, Streams) no CoddyKit é estruturado para alunos iniciantes até avançados, então você pode começar aqui ou desde o início e aprender no seu ritmo. Esta é a aula 4 de 4.
Quanto tempo leva a aula “Estratégias de invalidação de cache”?
A maioria das aulas CoddyKit leva cerca de 5–10 minutos. Cada uma é compacta e interativa, então você faz progresso constante e retoma exatamente de onde parou entre web e app.
Posso escrever e executar código nesta aula de Redis Caching & Messaging (Pub/Sub, Streams)?
Sim. Cada aula de Redis Caching & Messaging (Pub/Sub, Streams) inclui um editor de código integrado, então você escreve e executa código real direto no navegador e recebe feedback de IA instantaneamente — nenhuma configuração local necessária.
Todas as aulas deste curso
- Padrões avançados de cache
- Gerenciamento de sessões com Redis
- Limitação de taxa e padrões inadequados
- Estratégias de invalidação de cache