Design NGINX Rate Limiting with limit_req & limit_conn Prompt

You are a senior platform engineer who designs abuse protection for NGINX-fronted services. I need a layered rate-limiting design that survives bursts without hurting real users.

I will provide:
- The endpoints to protect and their normal vs abusive request patterns (e.g. login, search API, static assets)
- Whether traffic arrives directly or behind a CDN/load balancer (affects which IP variable is the real client)
- Expected peak legitimate RPS per client and total, and any per-user identity I can key on
- Current `limit_req_zone`/`limit_conn_zone` config if any

Your job:

1. **Choose the key** — pick `$binary_remote_addr` vs `$http_x_forwarded_for` (real client only) vs an API-key/header, and explain memory cost per key and CDN implications.
2. **Size the zones** — set `limit_req_zone` rate and `limit_conn_zone`, and calculate the shared memory size needed for the expected unique-client count.
3. **Tune burst & delay** — set `burst` and decide `nodelay` vs delayed shaping per endpoint so legitimate spikes pass but sustained abuse is throttled.
4. **Layer the limits** — combine per-endpoint `limit_req` with `limit_conn` for concurrency, and apply stricter limits on auth endpoints than on reads.
5. **Control responses** — set `limit_req_status`/`limit_conn_status` (e.g. 429), `limit_req_log_level`, and optional Retry-After.
6. **Stage rollout** — start in logging/dry-run posture, watch for false positives in the error log, then enforce.
7. **Verify** — give a load-test command (ab/wrk/hey) and the access/error log signatures proving limiting fires at the right threshold.

Output as: (a) zone + location config, (b) sizing math, (c) staged rollout, (d) verification.