← Concepts

阅读中文版本

Request Deduplication

Request deduplication collapses identical concurrent calls for the same resource into one upstream request and shares the result with all callers.

caching

Definition

Request deduplication is a technique that detects multiple in-flight requests for the same key and serves them from a single upstream operation, attaching the shared result to every caller.

Context and scope

It is valuable for expensive fetches that many concurrent clients request at once, such as a popular profile or a configuration document.

Common misconceptions

  • deduplication caches the result for later requests
  • it works for every request regardless of method

Anti-patterns

  • deduplicating requests with side effects such as payments
  • sharing an error result with all callers and never retrying

Related concepts

Related examples

Authoritative source

https://en.wikipedia.org/wiki/Data_deduplication

Definition

Request deduplication is a technique that detects multiple in-flight requests for the same key and serves them from a single upstream operation, attaching the shared result to every caller.

It is valuable for expensive fetches that many concurrent clients request at once, such as a popular profile or a configuration document. Compared to simpler alternatives, this concept fits best when the trade-off it represents is the one the system actually cares about.

When to use it

A common use case is applying it at the boundary where the cost of getting it wrong is highest, and the scenario usually involves a concrete guarantee the system must uphold. Unlike an ad hoc approach, it makes that guarantee explicit, reviewable, and testable.

How it works

The first caller starts the upstream operation and later callers attach to its pending promise or future, so the origin sees one request instead of many.

Deduplication covers only the window while a request is in flight; once it completes, the result is gone unless a separate cache retains it.

Trade-offs and alternatives

It should apply to idempotent reads, and failure handling must decide whether a failed shared result is retried or surfaced to every waiter. The main drawback is the extra complexity it introduces, so the benefit should clearly outweigh that cost before a team adopts it.

Common misconceptions

A persistent misconception is that deduplication caches the result for later requests. Another is that it works for every request regardless of method. For example, an engineer who assumes otherwise may design around a guarantee that does not actually exist, which only becomes obvious under load or failure.

Anti-patterns to avoid

Two recurring anti-patterns are to deduplicating requests with side effects such as payments and to sharing an error result with all callers and never retrying. Both tend to surface as hard-to-debug production issues rather than obvious test failures. Related concepts include Cache-Control Directives, Cache Key Normalisation, Read-Through Caching.