Request Deduplication

Overview

Request Deduplication identifies repeated requests and prevents or suppresses repeated processing according to a defined operation identity. It differs from idempotent processing because deduplication focuses on recognizing repetition, while idempotent processing also ensures safe business behavior if repetition reaches downstream components.

The main risks include false positives that reject valid operations, false negatives that allow duplicates, hash ambiguity, and race conditions. It may use idempotency keys, request hashes, business references, or transport identifiers. The Request Deduplication implementation should bound attempts, preserve the original operation identity, and stop before retries amplify a dependency failure.

In production, teams should define ownership and apply canonical fingerprints, scoped keys, atomic insertion, bounded retention, concurrency handling, and audit records. Operational review of Request Deduplication should separate successful recovery from repeated attempts that only increase latency or load.

Useful measures include deduplication hit rate, false-positive count, duplicate execution count, and lookup latency. Request Deduplication is closely connected to Idempotent Request, Idempotency Store, and Webhook Deduplication. For Request Deduplication, a missing response should remain uncertain until status lookup or reconciliation confirms whether the original operation executed.

Metrics for Request Deduplication should separate first-attempt success, recovered operations, exhausted attempts, duplicate prevention, and added latency. A Request Deduplication decision should use documented method semantics and provider error classes rather than message text alone.

Manual intervention for Request Deduplication should begin only after automated status checks cannot determine a safe final outcome. Configuration changes to Request Deduplication should be versioned and tested under burst, timeout, dependency failure, and restart conditions.