Angular HttpClient × RxJS: preventing duplicate requests when multiple subscribers share one call

Direct answer

Yes: applying shareReplay(1) (or shareReplay({ bufferSize: 1, refCount: true })) to the HttpClient Observable at the service level is sufficient to guarantee one network request for N concurrent subscribers, including the resolver-plus-template case. The cold HttpClient Observable becomes a shared, replayed stream: the first subscriber (typically the route resolver, which subscribes before the component renders) triggers the single GET, and both async pipe bindings then receive the replayed emission without new requests.

On error, shareReplay does not cache the error permanently in the way people fear, but the nuance matters: when the shared source errors, the error is delivered to current subscribers, and the shared stream resets — the next subscriber triggers a fresh underlying request. So a failed request does not stay failed for later subscribers; a later subscription retries implicitly. If you want explicit control (e.g., don't auto-retry on next subscription), you need your own reset/retry logic.

Interceptors run once per actual HTTP request, not per subscriber of the shared Observable — but they do re-run on every new underlying request, including each retry() resubscription and any post-error resubscription. Write interceptor side effects (token refresh, logging, metrics) to be idempotent.

Recommended service pattern

@Injectable({ providedIn: 'root' })\nexport class UserService {\n  private http = inject(HttpClient);\n  private users$?: Observable<User[]>;\n\n  getUsers(): Observable<User[]> {\n    if (!this.users$) {\n      this.users$ = this.http.get<User[]>('/api/users').pipe(\n        shareReplay({ bufferSize: 1, refCount: true })\n      );\n    }\n    return this.users$;\n  }\n\n  refresh(): void {\n    this.users$ = undefined; // next subscriber triggers a new request\n  }\n}

The refCount: true option means the underlying subscription is torn down when all observers unsubscribe, which avoids holding the connection alive indefinitely and gives you natural reset behavior when the route is left. If you want the value to survive navigation (true caching), use plain shareReplay(1) and invalidate manually via refresh().

Resolver and template wiring

Have the resolver return userService.getUsers() and bind the template with the async pipe against the same service method (or against the resolved data). Because the resolver subscribes first during navigation, the request fires once; the async pipes subscribe later and get the replayed value synchronously.

Verification

1. Open browser devtools Network tab, navigate to the route with two async pipe bindings plus the resolver. Confirm exactly one GET appears.
2. Force a 500 from the endpoint. Confirm current subscribers receive the error, then trigger a new subscription (e.g., re-navigate) and confirm a fresh request is issued — demonstrating the error is not permanently cached.
3. Add a logging interceptor and confirm it logs once per actual network request, and again per retry attempt.

Assumptions and caveats

This assumes RxJS 7 (per your lockfile) and a current Angular major with provideHttpClient(). The error-reset behavior described is the RxJS 7 default for shareReplay; if you rely on specific error semantics, verify against your exact RxJS minor version, since shareReplay configuration defaults changed between RxJS 6 and 7. If consumers subscribe at very different times and you need them all to share one in-flight request but not a stale cached value, consider whether a cache TTL or explicit invalidation fits better than an ever-living replay.