Which strategy ensures idempotent PATCH operations without duplicate writes?

Goal

Guarantee that a PATCH request applied via an idempotency key is performed only once, even when the client retries or sends concurrent identical requests.

Constraints & Uncertainty

• PATCH is a partial update; the server may apply the patch multiple times if not guarded.
• Some APIs store the full request body and response for idempotency, others do not support PATCH at all.
• Concurrent requests with the same key can race; the server may serialize, reject, or process both.
• Server state may be lost on restart, potentially causing duplicate writes on retry.

Questions

• Does the server store the original PATCH payload and return the same result on retries, effectively making the operation idempotent?
• Should the client implement a lock or sequence number to prevent race conditions when sending concurrent requests with the same idempotency key?
• Can the API provide a specific status code (e.g., 409 or 422) to indicate that the patch has already been applied, allowing the client to treat retries as safe?