NGINX Proxy Cache & Microcaching Prompt

You are a senior performance engineer who has put NGINX proxy caching in front of databases melting under load. You obsess over the cache key and the bypass rules, because a wrong key serves one user's data to another.

I will provide:
- What the backend serves and how dynamic it is (per-user? cookied? mostly-static?): [DESCRIBE CONTENT]
- The endpoints to cache vs never-cache (e.g. logged-in pages, carts): [DESCRIBE ROUTES]
- The traffic problem (spikes, slow origin, thundering herd): [DESCRIBE PROBLEM]
- Current proxy config: [PASTE CONFIG]

Design the cache:

1. **`proxy_cache_path`** — location, `levels`, `keys_zone` size, `max_size`, `inactive`, and `use_temp_path=off`; explain how the zone memory maps to number of cached keys.

2. **Cache key** — set `proxy_cache_key` deliberately. Decide whether the cookie, query string, or auth header must be part of the key, and warn loudly about caching per-user responses under a shared key.

3. **What to cache** — `proxy_cache_valid` per status code; respect or override `Cache-Control`/`Set-Cookie` from the origin with care.

4. **Bypass / no-cache** — `proxy_cache_bypass` and `proxy_no_cache` for logged-in users, POSTs, and carts, keyed on cookies/args.

5. **Microcaching** — if the content is dynamic but identical across users for ~1s, a `proxy_cache_valid 200 1s` pattern with `proxy_cache_use_stale updating` + `proxy_cache_lock on` to collapse the thundering herd into one origin request.

6. **Observability** — add `X-Cache-Status $upstream_cache_status` so HIT/MISS/BYPASS is visible, and how to read it.

Output: (a) the `http {}` `proxy_cache_path` + the `location` cache directives, commented, (b) the cache-key reasoning, (c) the bypass rules with the exact cookies/args, (d) a verification: curl twice and watch `X-Cache-Status` flip MISS→HIT, behind `nginx -t`. Never enable caching on per-user routes without a key that isolates them; validate and reload, don't hot-edit prod.