request path

Walk of GET /alice/stats with Redis on.

1. CORS middleware (added first, runs second).
2. CacheRateLimitMiddleware with platform="leetcode" (added last, runs first).
3. Skip check. Path is not /, /docs, /redoc, /openapi.json, /favicon.ico. Method is GET. Redis is on.
4. Handle is the first path segment, lowercased: alice.
5. Cache key is cache:leetcode:{sha256(GET:/alice/stats:sorted_query)}.
6. On HIT, body is base64-decoded and returned with X-Cache: HIT. Done.
7. Negative key invalid:leetcode:alice. On HIT, HTTP 404 User does not exist, X-Cache: NEGATIVE-HIT. Invalid-user rate limits apply (10/IP and 5/handle per 10 minutes).
8. Live limits: 60 req/min per IP, 30 req/min per handle. Over: 429 with Retry-After and exponential backoff 5s to 300s.
9. Route get_stats calls get_user_stats (GraphQL getUserProfile) and _topics (GraphQL skillStats).
10. stats_from builds canonical Stats including topicAnalysis.
11. make_envelope wraps it. HTTP 200 cached for 3600s unless Cache-Control says otherwise. X-Cache: MISS.

Without Redis, steps 5 to 8 disappear. Every GET hits GraphQL. Rate limits disappear too. That is fine on a laptop and noisy on a public host.

sequenceDiagram
  participant B as Browser
  participant MW as CacheRateLimit
  participant R as Redis
  participant RT as stats route
  participant G as leetcode.com/graphql

  B->>MW: GET /alice/stats
  MW->>R: GET cache:leetcode:digest
  alt hit
    R-->>MW: body
    MW-->>B: 200 X-Cache HIT
  else miss
    MW->>R: GET invalid:leetcode:alice
    MW->>R: INCR rl:ip and rl:handle
    MW->>RT: call_next
    RT->>G: getUserProfile
    RT->>G: skillStats
    RT-->>MW: envelope
    MW->>R: SETEX cache 3600s
    MW-->>B: 200 X-Cache MISS
  end

IP is X-Forwarded-For first hop, else X-Real-IP, else request.client.host. Vercel sits in front, so the forwarded header is the one that matters.

/playground is not in SKIP_PATHS. With Redis on, the first path segment is treated as handle playground. Harmless, slightly weird. /ph/... becomes handle ph for the same reason.

REDIS_URL turns the middleware on. There is no in-process HTTP cache on LeetCode (CodeChef is the sibling that also has TTLCache). Redis errors fail open: cache miss, rate limit allow. Bind ports and HTML routes stay on Cache, rate limit, and deploy.

Keys:

• cache:leetcode:{sha256}
• invalid:leetcode:{handle}
• rl:ip:leetcode:{ip} / rl:handle:leetcode:{handle}
• backoff:{same} / violations:{same}

Invalid-user markers: user does not exist, user not found, not found on, invalid username. Contest-empty is not one of them.