Rate-limit counters, an idempotency-key deduplication table, and a response cache are all server-side data that persists between requests. Explain which of these are compatible with a stateless HTTP API and what makes the difference.

## Restating the constraint precisely Statelessness does not say the server remembers nothing. It says the server must not require **per-client interaction context carried over from that client's earlier requests** in order to understand the current one. Everything else - durable resources, derived caches, operational bookkeeping - is allowed. Two tests decide any candidate: 1. **Self-description**: does the request still mean the same thing on its own, without the server recalling the client's previous call? 2. **Interchangeability**: is the data reachable identically by every instance, so a different node handles the request correctly? ## Response caches A cache holds copies of data that can be recomputed. Correctness must never depend on a hit: a freshly started instance with an empty cache must return the same answer, only slower. That makes caches a pure optimisation, and HTTP is designed around them - `Cache-Control`, `ETag` and validators exist precisely so intermediaries can cache. A local in-process cache is fine under this rule, with two caveats. First, invalidation is now per-instance, so stale windows differ between nodes and a user can see values flip as routing changes; that is a consistency problem, not a statelessness violation. Second, if the cache holds *per-client* data that exists nowhere else, it stops being derived data and becomes hidden session state - that is a violation. ## Idempotency-key deduplication A client sends a unique key with a non-safe request, typically in the `Idempotency-Key` header, so a retry after a timeout does not create a second charge or order. The server records the key with the outcome and, on seeing it again, returns the stored result instead of re-executing. This is server-side state that persists across requests - and it is entirely compatible, for a clean reason: **the client supplies the correlation**. The request still fully describes itself; the server does not need to remember anything about the client to interpret it. The dedupe record is bookkeeping about a completed operation, closer to a resource than to a conversation. It must, however, live in storage every instance reads, because retries frequently land elsewhere - that is the whole point of retrying after a failure. A per-instance dedupe map would let a retry through on another node and defeat the mechanism. Practical details: store the key plus a fingerprint of the request so the same key with different content is rejected rather than silently returning the wrong result; scope the key to the caller so tenants cannot collide or probe; record an in-progress marker so two concurrent requests with one key do not both execute; and expire records after a defined window. ## Rate-limit counters Counters are the interesting case, because they are per-client by nature. Statelessness is not violated by counting - the request is still self-describing, since the client's identity comes from its own credential. What matters is placement. A **local** counter makes the enforced limit depend on how many instances exist and how requests are routed: with ten instances and round-robin, a per-instance limit of 100 permits roughly 1000. Scale out and the limit silently loosens; scale in and it tightens. Worse, a client's observed behaviour changes with routing, which is exactly the interchangeability failure. A **shared** counter with atomic increments enforces one global limit regardless of routing and instance count. The usual production compromise is a local token bucket synchronised periodically against a shared budget: it removes a network hop from the hot path while keeping the global limit roughly accurate. That is a deliberate accuracy-for-latency trade, and worth naming as such. ## The general rule Allowed server-side state: resources, derived caches, dedupe and audit records, counters and locks - provided they are shared and the request remains self-describing. Disallowed: anything a request's *meaning* depends on that only one instance knows. When in doubt, ask what a cold instance would do with this exact request.