Fastify request lifecycle and Redis idempotency store: duplicate POST handling at integration boundary

Goal is to prevent duplicate writes when clients retry POST requests that pass through Fastify routes to a downstream data store. Fastify provides no built-in idempotency or retry deduplication, so the integration boundary between the request lifecycle hooks/plugins and an external dedup store must be defined by application code.

Encapsulation allows scoping deduplication per route context, and hook ordering determines when an Idempotency-Key can be reliably read from headers versus body. Proxy style plugins do not add idempotency semantics, so retries are re-executed downstream unless the Fastify layer enforces it.

One unresolved decision is the handling of concurrent duplicates while the original request is still in-flight. Fastify does not provide a request-coalescing primitive, leaving the policy to the plugin author.

Should duplicates arriving during in-flight processing be rejected, wait for completion, or be allowed to proceed? How does encapsulation affect visibility of a shared dedup store across sibling route prefixes? Does placement of the check in onRequest versus preHandler change reliability when body parsing is involved?