Test your knowledge: Nginx Caching

Question 1 of 6

The first question of NGINX cache design is not 'how long' but what?

Everything downstream (TTL, purge, staleness) is defined relative to it.

Answer options A Which compression to store B What the cache key should be — the exact request identity that maps to one stored response C Where the cache directory lives D How much RAM to give the zone

The key decides identity: $scheme$proxy_host$request_uri as the floor, plus Accept-Encoding, logged-in markers, or headers when they change the response. A wrong key serves one user another user's page — the cardinal cache sin.

Review this lesson

Question 2 of 6

`proxy_cache_path /var/cache/nginx keys_zone=api:10m max_size=2g inactive=60m;` — what does `inactive` mean?

It is about eviction of unused files, not TTL.

Answer options A How long a cache miss can last B Files untouched for 60 minutes are deleted from the cache, regardless of freshness headers C The zone sleeps after 60 minutes without traffic D Cache entries expire 60 minutes after creation

inactive is the janitor: files not accessed within it are removed even if their TTL still has time left. TTL freshness is proxy_cache_valid's business; inactive is disk-space hygiene.

Review this lesson

Question 3 of 6

`proxy_cache_valid 200 301 10m; 404 1m;` — what does this control?

It is the fallback TTL, not the client-facing one.

Answer options A How long clients may cache each status B How long NGINX considers a cached response of that status fresh when the backend sent no cache headers C Retry backoff per status D The log retention per status

proxy_cache_valid sets freshness per status when the response has no Cache-Control/Expires of its own. Explicit backend cache headers win unless you force proxy_ignore_headers to flip the priority.

Review this lesson

Question 4 of 6

`proxy_cache_use_stale error timeout updating;` — what does `updating` unlock?

It is half of the thundering-herd cure; the lock is the other half.

Answer options A Revalidation of expired entries on a timer B Serving the stale copy to everyone while one worker refreshes it — instead of stampeding the backend C Background cache warming at startup D Using stale entries only for GET requests

Together with proxy_cache_lock, updating lets one request re-fetch while others get the stale answer immediately — stale-while-revalidate semantics at the edge. error/timeout cover the backend-out case: stale beats 502.

Review this lesson

Question 5 of 6

A popular object expires and 500 parallel requests all miss. What does `proxy_cache_lock on;` do?

Request collapsing is the term.

Answer options A Rejects the extra 499 requests B Lets one request through to the backend; the rest wait for it to populate the cache (collapse) C Locks the cache file against writes forever D Duplicates the response across workers

The lock serializes the miss: one origin fetch, everyone else served from the freshly filled entry. Combine with updating and waiters never even see a delay — the herd never reaches the backend.

Review this lesson

Question 6 of 6

The `slice` module ( `slice 1m;`) makes large-file proxying cacheable how?

Think partial-content caching.

Answer options A It compresses each file into 1 MB blocks B Range requests are served from independently cached 1 MB slices, fetched from the origin in parallel C It splits the cache zone into 1 MB shards D It limits uploads to 1 MB

slice chops the requested range into fixed-size subrequests whose responses are cached individually — a client's byte-range hit only touches its slices, and different ranges share overlapping slices. Needs the $slice_range header forwarded.

Review this lesson

Test your knowledge: Nginx Caching