Nitro server route idempotency and request deduplication

To implement request deduplication in Nitro across distributed instances, you must use a custom H3 middleware that utilizes a shared, atomic key-value store (like Redis) to track idempotency keys. Since Nitro does not provide a native configuration for this, the logic resides in intercepting the event before it reaches the server route handler. ### Implementation Strategy via Middleware nThe most effective approach is to create a global or route-specific middleware that extracts a unique idempotency key (e.g., an `Idempotency-Key` header). The workflow follows these steps: 1. **Extract the Key**: Retrieve the idempotency key from the request headers. If missing, you may choose to proceed without deduplication or return a `400 Bad Request`. 2. **Atomic Check and Set**: Use an atomic operation `SET NX` (set if not exists) in a distributed store like Redis. This ensures that even if two instances receive the same request simultaneously, only one succeeds in setting the key. 3. **Handle the Result** - If the set is successful: Proceed to the H3 handler. Store the response (status, headers, and body) in Redis associated with that key before returning it. n - If the set fails: The request is either being processed or has completed. Retrieve the cached response from Redis and return it immediately without executing the handler logic. 4. **TTL Management**: Set a reasonable Time-To-Live (TTL) on the keys to prevent the key-value store from growing indefinitely. ### Maintaining State without Latency To avoid introducing significant latency to the H3 event loop, follow these best practices:

• **Asynchronous I/O**: Use non-blocking Redis clients (e.g., `ioredis`) to ensure the event loop is not stalled while waiting for the store response.
• **Data Locality**: Deploy your Redis instance in the same region/VPC as your Nitro deployment to minimize round-trip time (RTT).
• **Optimistic Processing**: If a request is currently in progress (key exists but response is not cached), return a `409 Conflict` status to tell the client to wait and retry later, rather than holding the connection open.
n

### Assumptions and Uncertainty This solution assumes you are operating in a distributed environment (serverless or multi-container) where local in-memory storage is insufficient. It also assumes the client is capable of generating and sending unique keys for mutation requests. One uncertainty remains regarding the size of the response body; storing large payloads in Redis can increase memory costs, so consider storing only the status and metadata for very large responses.