Per-view caching in Django - Step-by-Step Execution

Concept Flow - Per-view caching

User sends HTTP request

↓

Django receives request

↓

Check cache for view response

↓

Return cached

↓

Send response

↓

Send response

The flow shows how Django checks if a cached response exists for a view before running it, returning cached data if found, or running and caching the view output if not.

Execution Sample

Django

@cache_page(60)
def my_view(request):
    return HttpResponse('Hello World')

This code caches the response of my_view for 60 seconds, so repeated requests within that time get the cached response.

Execution Table

Step	Action	Cache Check Result	View Execution	Response Sent
1	User sends request to my_view	Cache miss (no cached response)	my_view runs, returns 'Hello World'	Response 'Hello World' sent and cached
2	User sends request again within 60 seconds	Cache hit (cached response found)	View not executed	Cached response 'Hello World' sent
3	User sends request after 60 seconds	Cache expired (no cached response)	my_view runs again, returns 'Hello World'	Response 'Hello World' sent and cached again

💡 Execution stops after sending response; cache is checked each request to decide if view runs or cached response is used.

Variable Tracker

Variable	Start	After Step 1	After Step 2	After Step 3
cache	empty	contains 'my_view' response	contains 'my_view' response	contains refreshed 'my_view' response
view_executed	False	True	False	True
response_sent	None	'Hello World'	'Hello World' (cached)	'Hello World'

Key Moments - 2 Insights

Why doesn't the view function run on the second request?

Because the cache contains a valid response from the first request (see execution_table step 2), Django returns the cached response directly without running the view.

What happens when the cache expires after 60 seconds?

The cache no longer has a valid response (execution_table step 3), so Django runs the view again and caches the new response.

Visual Quiz - 3 Questions

Look at the execution table, what is the cache status at step 2?

A Cache hit with cached response

B Cache miss, view runs

C Cache expired, view runs

D Cache empty

💡 Hint

Check the 'Cache Check Result' column at step 2 in the execution_table

At which step does the view function execute again after cache expiration?

A Step 1

B Step 2

C Step 3

D Never

💡 Hint

Look at the 'View Execution' column in execution_table for when the view runs

If the cache timeout was changed to 120 seconds, how would step 3 change?

A Step 3 would be a cache miss, view executed

B Step 3 would be a cache hit, view not executed

C Step 3 would not happen

D Step 3 would send no response

💡 Hint

Longer cache timeout means cached response still valid at step 3 (see variable_tracker cache variable)

Concept Snapshot

Per-view caching in Django uses @cache_page(seconds) decorator.
It stores the full HTTP response for the view.
On requests, Django checks cache first.
If cached, returns it immediately.
If not, runs view, caches response, then returns it.
Cache timeout controls how long response is stored.

Full Transcript

Per-view caching in Django works by storing the full response of a view for a set time. When a user sends a request, Django first checks if a cached response exists. If yes, it returns that cached response without running the view function again. If no cached response exists or the cache expired, Django runs the view, caches the new response, and sends it back. This speeds up repeated requests by avoiding repeated view processing. The cache timeout defines how long the response stays cached before Django runs the view again.