Django inclui um framework de cache flexível que suporta múltiplos níveis de cache (páginas inteiras, resultados de views, fragmentos de templates ou dados arbitrários) e múltiplos backends (em memória, Redis, Memcached, banco de dados). O cache evita repetir trabalho custoso — uma das otimizações de desempenho de maior impacto.
CACHES = {
: {
: ,
: ,
}
}
# 1. Per-view caching — cache an entire view's output
from django.views.decorators.cache import cache_page
@cache_page(60 * 15) # cache this view's response for 15 minutes
def article_list(request):
...
<!-- 2. Template fragment caching — cache part of a template -->
{% load cache %}
{% cache 500 sidebar %}
... expensive sidebar rendering ... <!-- cached for 500 seconds -->
{% endcache %}
# 3. Low-level cache API — cache ANY data, full control
from django.core.cache import cache
def get_stats():
stats = cache.get("dashboard_stats") # check cache first
if stats is None: # cache MISS
stats = compute_expensive_stats() # do the work
cache.set("dashboard_stats", stats, 3600) # store for 1 hour
return stats
Django permite cache em múltiplas granularidades: páginas inteiras (cache_page), fragmentos de templates ({% cache %}), e dados arbitrários via a API de baixo nível (cache.get/cache.set — o padrão flexível get-or-compute). Há também cache de site completo via middleware.
# when underlying data changes, the cache must be updated or cleared, or users see stale data
def update_article(article):
article.save()
cache.delete("article_list") # invalidate affected cache entries
# strategies: TTL (accept brief staleness), explicit deletion on writes, versioned keys,
# or signals to invalidate on model save/delete
Cache invalidation is the classic hard problem: when data changes, stale cached
values must be cleared/refreshed. Approaches: short TTLs (accept some staleness),
explicit cache.delete on writes, or cache versioning/key schemes.
✓ Expensive queries/computations, rendered pages/fragments that change infrequently
✓ Aggregations, external API responses, session data
✗ Highly personalized or rapidly-changing data (or use very short TTLs / vary per user)
✗ Don't cache sensitive data carelessly (consider who can read the cache)
O cache é uma das otimizações de desempenho de maior impacto para aplicações Django, e o sistema de cache abrangente e multi-nível do framework a torna acessível — compreender isso é um conhecimento valioso de nível senior para construir aplicações rápidas e escaláveis.
O valor central é evitar trabalho custoso repetido: queries de banco de dados, computações complexas, chamadas a APIs externas e rendering de templates podem ser cacheados para que requisições subsequentes sejam servidas rapidamente, reduzindo drasticamente a latência e a carga no banco de dados/servidor.
A flexibilidade do Django em múltiplos níveis de cache (páginas inteiras com cache_page, fragmentos de templates com {% cache %}, e dados arbitrários via o padrão get-or-compute da API de baixo nível) permite cachear na granularidade exata para cada situação, e seus backends plugáveis (especialmente Redis para um cache compartilhado entre múltiplos servidores — importante porque caches em memória por-processo não são compartilhados ao escalar horizontalmente) se adequam a diferentes necessidades de deployment.
Saber como configurar cache, escolher o nível apropriado e selecionar o backend certo para o deployment é um conhecimento prático e frequentemente necessário.
Igualmente importante é compreender a dificuldade central do cache — invalidação (o famosamente difícil problema de limpar ou atualizar dados cacheados quando os dados subjacentes mudam, via TTLs, exclusão explícita em escritas ou versionamento de chaves, para evitar servir dados obsoletos) — já que errar nisso é a falha clássica de cache que mostra aos usuários informações desatualizadas.
Também saber o que cachear (dados custosos e que mudam infrequentemente) versus o que não (dados altamente dinâmicos ou sensíveis) é essencial para usar cache efetivamente.
Porque o cache fornece ganhos de desempenho significativos mas requer invalidação cuidadosa, dominar o framework de cache do Django — os níveis, backends e especialmente as estratégias de invalidação — é um conhecimento importante para construir aplicações performáticas e escaláveis, e uma marca registrada de desenvolvedores que conseguem fazer apps Django rápidas sob carga real.