RxJS shareReplay HTTP Cache Guide

Learn how to apply shareReplay to avoid duplicate HTTP requests, set trust boundaries, check operation, and recognize when the design must evolve.

Requirements

In an Angular application, a service method that wraps HttpClient.get often needs to:

Prevent duplicate network calls when multiple components subscribe at the same time.
Automatically clean up the underlying subscription when no consumers remain, to avoid dangling requests and memory leaks.
Propagate errors to each subscriber unless a fallback is explicitly provided.
Allow optional manual control of the cached value’s lifetime (e.g., stale‑while‑revalidate).

Smallest Suitable Design

The minimal RxJS construction that satisfies the above is:

import { HttpClient } from '@angular/common/http';\nimport { shareReplay } from 'rxjs/operators';\n\n@Injectable({ providedIn: 'root' })\nexport class DataService {\n  constructor(private http: HttpClient) {}\n\n  fetchData() {\n    return this.http.get('/api/data').pipe(\n      shareReplay(1) // bufferSize = 1, refCount defaults to true\n    );\n  }\n}\n

shareReplay(1) creates a hot observable that:

Subscribes to the cold http.get source on the first subscriber.
Buffers the latest successful emission and replays it to any later subscriber.
When the subscriber count drops to zero, the internal subscription is automatically disposed because refCount defaults to true.

Trust / Data Boundaries

The trust boundary lies between the cold source (HttpClient.get) and the hot observable produced by shareReplay:

Cold side: Each call to get creates a new XHR/fetch; no side‑effects occur until subscription.
Hot side: After the first subscription, all downstream consumers share the same underlying request; they cannot affect the source directly.

Thus, the service guarantees that at most one HTTP request is in flight for a given call to fetchData(), regardless of how many components subscribe.

Operational Checks

To verify the design works as intended:

Open the browser’s Network tab.
In a component, subscribe twice in quick succession:

this.dataService.fetchData().subscribe();\nthis.dataService.fetchData().subscribe();\n

Confirm that only a single request to /api/data appears.
After both subscriptions are unsubscribed (e.g., via ngOnDestroy or manual unsubscribe()), wait a short interval and ensure no further requests are triggered.
Optionally, inspect the returned observable’s internal state by adding a tap operator that logs when the source subscription is created and destroyed.

These checks confirm that the trust boundary is respected and that resource cleanup occurs.

Failure Modes

Incorrect refCount: If you explicitly set shareReplay(1, false) or shareReplay(1, undefined, false), the internal subscription remains alive after all subscribers leave, causing persistent HTTP requests and a memory leak.
Error propagation: By default, shareReplay does not cache error notifications. A failed request will be re‑executed for each new subscriber unless you handle errors upstream, e.g., catchError(() => of(fallbackData)).
Scheduler mismatches (RxJS < 7): Versions prior to 7 lack a scheduler argument; using shareReplay with async operations that depend on a specific scheduler may yield unexpected timing (e.g., delayed completions).
Stale data: The buffer holds only the latest successful value. If the source observable completes (as HTTP does), late subscribers receive that value forever, even if the backend data has changed.

Conditions That Would Change the Design

Revisit the design when any of the following arise:

Need to cache multiple distinct values (e.g., paginated lists). Increase bufferSize or switch to a dedicated caching operator like publishReplay with manual ref‑counting.
Require a stale‑while‑revalidate strategy: keep the cached value while issuing a background refresh. Combine shareReplay with expand or repeat and a timer.
Want to control the lifetime manually (e.g., logout clears cache). Set refCount: false and manage the subscription via a Subject or takeUntil.
Must cache errors as well (e.g., show a persistent error message). Apply catchError before shareReplay to transform errors into a successful emission.
Operating in an environment where RxJS version is below 7 and scheduler sensitivity matters; upgrade or explicitly pass a scheduler to shareReplay if available.

When any of these conditions appear, the smallest design (shareReplay(1)) is no longer sufficient, and a more elaborate caching architecture should be considered.

Using RxJS shareReplay as a Simple HTTP Cache in Angular Services