Chapter 9: API Caching, Invalidation, and Request Deduplication

Introduction

Welcome to Chapter 9! In the fast-paced world of web applications, user experience and application performance are paramount. Nobody likes waiting for data to load, especially if it’s data they’ve already seen or data that changes infrequently. This is where API caching and request deduplication come into play. These powerful techniques allow your Angular application to store frequently accessed data locally and prevent unnecessary duplicate network requests, leading to a snappier, more responsive user interface and reduced load on your backend servers.

In this chapter, we’ll dive deep into how to implement robust client-side caching and request deduplication strategies using Angular’s HttpClient and HttpInterceptor with the power of RxJS, all within the modern standalone architecture. We’ll explore various caching mechanisms, learn how to intelligently invalidate cached data when it becomes stale, and discover how to prevent your application from making the same network request multiple times in quick succession. By the end of this chapter, you’ll have the tools to significantly optimize your application’s network interactions and provide a smoother experience for your users.

Before we begin, ensure you’re comfortable with Angular’s HttpClient for making API calls and have a solid understanding of HttpInterceptors from previous chapters. Familiarity with RxJS observables, operators like tap, of, shareReplay, and finalize will also be beneficial.

Why Cache? The Problem and the Solution

Imagine your application displays a list of users. Every time a user navigates to the ‘Users’ page, or perhaps clicks a refresh button, your application fetches the entire list from the server. Now, what if hundreds of users do this simultaneously? Or what if the user repeatedly switches between the ‘Users’ page and another page?

The Problem:

Performance: Repeatedly fetching the same data over the network is slow. Network latency is often a major bottleneck in web applications.
User Experience (UX): Users experience loading spinners or blank screens while waiting for data that might not have changed. This leads to frustration.
Server Load: Constant, redundant requests put unnecessary strain on your backend servers, potentially impacting their stability and scalability.
Cost: For cloud-based APIs, more requests often mean higher operational costs.

The Solution: Caching Caching involves storing a copy of data closer to where it’s needed – in our case, within the user’s browser or application memory. When the application requests data, it first checks the cache.

Cache Hit: If the data is in the cache and still considered valid, the application serves the cached copy immediately. Fast, efficient!
Cache Miss: If the data is not in the cache or is deemed stale, the application fetches it from the server, stores a fresh copy in the cache, and then serves it to the user.

This simple mechanism dramatically reduces network traffic, speeds up data retrieval, and improves the overall responsiveness of your application.

Request Deduplication: A Partner to Caching

Beyond caching, there’s another common scenario: a user rapidly clicks a button that triggers an API call, or multiple components on the same page independently request the same data simultaneously. Without deduplication, your application would send multiple identical requests to the server.

Request Deduplication is the process of identifying and consolidating these identical, concurrent requests into a single network call. When multiple parts of your application ask for the same data at the same time, the deduplication logic ensures only one actual HTTP request goes out. All subsequent identical requests then “subscribe” to the observable of that single ongoing request, sharing its result when it completes. This further reduces network traffic and server load.

Let’s visualize this flow:

flowchart TD A[Component requests data] --> B{Is this request already pending?} B -->|Yes| C[Return existing pending Observable] B -->|No| D{Is data in cache and valid?} D -->|Yes| E[Return cached data immediately] D -->|No| F[Make new HTTP request] F --> G[Store request as pending] F --> H[Server responds] H --> I[Cache response] I --> J[Remove request from pending] I --> K[Return response to all subscribers] C --> K E --> K

Core Concepts for Client-Side Caching

When implementing client-side caching, we primarily focus on in-memory caching for speed and simplicity, often managed via an HttpInterceptor.

In-Memory Cache:
- What it is: A simple JavaScript Map or object literal stored within your Angular service or interceptor.
- Why use it: Extremely fast lookup times, easy to implement.
- How it works: Stores HttpResponse objects keyed by the request URL (and potentially other parameters).
- Limitation: Data is lost when the user closes the tab or refreshes the page. Not suitable for persistent storage across sessions.
Cache Invalidation Strategies: The core challenge of caching isn’t how to store data, but when to get rid of it. Stale data is worse than no data.
- Time-To-Live (TTL) / Time-Based Invalidation:
  - What it is: Each cached item has an expiration time. After this time, the item is considered stale and must be re-fetched.
  - Why use it: Simple for data that changes predictably or data where a small delay in freshness is acceptable (e.g., a list of static categories).
  - How it works: Store the timestamp of when the item was cached along with the data. When retrieving, check if currentTime - cachedTime > TTL.
- Event-Based Invalidation:
  - What it is: Cached data is explicitly invalidated when a specific event occurs, typically a data modification operation (e.g., a POST, PUT, or DELETE request to the same resource).
  - Why use it: Ensures data freshness immediately after changes. Ideal for critical data where staleness is unacceptable.
  - How it works: After a modifying HTTP request completes successfully, iterate through the cache and remove relevant entries. This often requires a clear convention for cache keys.
- Stale-While-Revalidate (SWR):
  - What it is: A popular strategy where, on a cache hit, the cached data is immediately returned to the UI (stale data), while a new request is simultaneously made in the background to re-fetch fresh data. Once the fresh data arrives, the cache is updated, and the UI can be updated again if the data changed.
  - Why use it: Provides an instant user experience (no loading spinner) while ensuring eventual data freshness. Excellent for lists or data that can tolerate brief staleness.
  - How it works: More complex to implement, often involving RxJS concat or similar patterns to emit the cached value first, then the network value. We’ll focus on simpler TTL and event-based in this chapter.

Step-by-Step Implementation: Building a Smart Caching and Deduplication Interceptor

We’ll create a single CacheInterceptor that handles both in-memory caching with TTL and request deduplication for GET requests. We’ll also build a CacheService to allow explicit invalidation.

Angular Version: For this guide, we’ll assume Angular v18.0.0 or later (as of 2026-02-11), utilizing the standalone API.

Step 1: Create the `CacheService`

This service will manage our in-memory cache and provide methods for invalidation.

// src/app/core/services/cache.service.ts
import { Injectable } from '@angular/core';
import { HttpResponse } from '@angular/common/http';

interface CacheEntry {
  response: HttpResponse<any>;
  timestamp: number;
  maxAge: number; // Max age in milliseconds
}

@Injectable({
  providedIn: 'root'
})
export class CacheService {
  private cache = new Map<string, CacheEntry>();

  constructor() {
    console.log('CacheService initialized');
  }

  /**
   * Retrieves a cached response for a given URL.
   * @param url The request URL.
   * @returns The cached HttpResponse if valid, otherwise null.
   */
  get(url: string): HttpResponse<any> | null {
    const entry = this.cache.get(url);
    if (!entry) {
      return null;
    }

    const isExpired = Date.now() - entry.timestamp > entry.maxAge;
    if (isExpired) {
      console.log(`Cache expired for ${url}`);
      this.cache.delete(url); // Remove expired entry
      return null;
    }

    console.log(`Cache hit for ${url}`);
    return entry.response;
  }

  /**
   * Stores a response in the cache.
   * @param url The request URL.
   * @param response The HttpResponse to cache.
   * @param maxAge The maximum age for this cache entry in milliseconds.
   */
  put(url: string, response: HttpResponse<any>, maxAge: number = 30000): void {
    const entry: CacheEntry = { response, timestamp: Date.now(), maxAge };
    this.cache.set(url, entry);
    console.log(`Cached ${url} with maxAge ${maxAge}ms`);
  }

  /**
   * Invalidates a specific cache entry.
   * @param url The URL of the entry to invalidate.
   */
  invalidate(url: string): void {
    if (this.cache.has(url)) {
      this.cache.delete(url);
      console.log(`Invalidated cache for ${url}`);
    }
  }

  /**
   * Clears the entire cache.
   */
  clear(): void {
    this.cache.clear();
    console.log('Cache cleared');
  }
}

Explanation:

We define a CacheEntry interface to store the HttpResponse, a timestamp (when it was cached), and its maxAge.
The cache is a Map where keys are request URLs and values are CacheEntry objects.
get(url): Retrieves an entry. It checks if the entry exists and if it’s still within its maxAge. If expired, it deletes the entry and returns null.
put(url, response, maxAge): Stores a new entry with the current timestamp. The default maxAge is 30 seconds (30000ms).
invalidate(url): Allows external services or components to explicitly remove a specific entry from the cache.
clear(): Wipes out the entire cache.

Step 2: Create the `CacheInterceptor`

This interceptor will use the CacheService to manage caching and will also handle request deduplication.

// src/app/core/interceptors/cache.interceptor.ts
import { Injectable } from '@angular/core';
import {
  HttpRequest,
  HttpHandler,
  HttpEvent,
  HttpInterceptor,
  HttpResponse,
} from '@angular/common/http';
import { Observable, of, tap, shareReplay, finalize } from 'rxjs';
import { CacheService } from '../services/cache.service';

@Injectable()
export class CacheInterceptor implements HttpInterceptor {
  // Map to store pending requests for deduplication
  private pendingRequests = new Map<string, Observable<HttpEvent<any>>>();

  constructor(private cacheService: CacheService) {}

  intercept(
    request: HttpRequest<any>,
    next: HttpHandler
  ): Observable<HttpEvent<any>> {
    // Only cache/deduplicate GET requests
    if (request.method !== 'GET') {
      // For non-GET requests, we might want to invalidate related caches
      // Example: If a POST to /api/users occurs, invalidate /api/users GET cache
      if (request.url.includes('/api/users')) {
        this.cacheService.invalidate(request.url.replace('/api/users', '/api/users')); // Simple invalidation example
        // More sophisticated invalidation could be based on a pattern or specific keys
      }
      return next.handle(request);
    }

    // Check for a header to explicitly skip caching
    if (request.headers.get('x-skip-cache')) {
      console.log(`Skipping cache for ${request.url}`);
      // Clone the request to remove the custom header before passing it along
      const newRequest = request.clone({ headers: request.headers.delete('x-skip-cache') });
      return next.handle(newRequest);
    }

    // --- Request Deduplication Logic ---
    if (this.pendingRequests.has(request.urlWithParams)) {
      console.log(`Deduplicating request for ${request.urlWithParams}`);
      return this.pendingRequests.get(request.urlWithParams)!;
    }

    // --- Caching Logic ---
    const cachedResponse = this.cacheService.get(request.urlWithParams);
    if (cachedResponse) {
      console.log(`Returning cached response for ${request.urlWithParams}`);
      return of(cachedResponse);
    }

    // If no cached response and not pending, make the actual HTTP request
    const requestObservable = next.handle(request).pipe(
      // Cache the response if it's successful
      tap((event) => {
        if (event instanceof HttpResponse) {
          // You can extract maxAge from a custom header or use a default
          const customMaxAge = request.headers.get('x-cache-max-age');
          const maxAge = customMaxAge ? parseInt(customMaxAge, 10) : undefined;
          this.cacheService.put(request.urlWithParams, event, maxAge);
        }
      }),
      // Use shareReplay to ensure the underlying HTTP request is only made once
      // and all subscribers receive the same response.
      // `refCount: true` ensures the observable is unsubscribed when no longer needed.
      // `bufferSize: 1` ensures the last emitted value is replayed to new subscribers.
      shareReplay({ bufferSize: 1, refCount: true }),
      // Remove the request from pendingRequests map when it completes or errors
      finalize(() => {
        this.pendingRequests.delete(request.urlWithParams);
        console.log(`Removed pending request for ${request.urlWithParams}`);
      })
    );

    // Store the observable in pendingRequests map
    this.pendingRequests.set(request.urlWithParams, requestObservable);
    console.log(`New request pending for ${request.urlWithParams}`);

    return requestObservable;
  }
}

Explanation:

pendingRequests Map: A private Map to store Observable instances of ongoing HTTP requests, keyed by request.urlWithParams. This is crucial for deduplication.
intercept Method:
- Non-GET Requests: If the request method is not GET, we skip caching and deduplication. We also add a simple example of invalidating a related cache entry (e.g., if a POST to /api/users occurs, invalidate the /api/users GET cache). This is a basic example; real-world invalidation can be more complex.
- x-skip-cache Header: A custom header x-skip-cache allows a specific request to bypass the cache. We clone the request to remove this header before passing it to next.handle() to avoid sending custom interceptor headers to the backend.
- Request Deduplication:
  - It checks pendingRequests. If an observable for the current request.urlWithParams already exists, it means an identical request is already in flight. We return that existing observable, effectively deduplicating the request.
- Caching Logic:
  - It calls this.cacheService.get() to check if a valid cached response exists. If so, it immediately returns an of(cachedResponse), preventing a network call.
- New HTTP Request & Caching:
  - If no cached response and no pending request, the actual next.handle(request) is called.
  - tap((event) => ...): We use tap to intercept the HttpResponse (only on success) and store it in this.cacheService.put(). We also check for an optional x-cache-max-age header to allow per-request TTL configuration.
  - shareReplay({ bufferSize: 1, refCount: true }): This powerful RxJS operator is essential here.
    - shareReplay ensures that the underlying HTTP request (the next.handle(request)) is executed only once, even if multiple components subscribe to requestObservable.
    - bufferSize: 1 means it will replay the last emitted value to any new subscribers.
    - refCount: true means the underlying observable (the actual HTTP call) will only stay active as long as there is at least one subscriber. When the last subscriber unsubscribes, the HTTP call will be cancelled if it’s still ongoing (though HttpClient usually completes quickly).
  - finalize(() => ...): This operator executes a callback when the observable completes or errors. We use it to remove the request from pendingRequests, ensuring the map doesn’t grow indefinitely.
- Store Pending Request: Before returning requestObservable, we store it in pendingRequests so subsequent identical requests can find and reuse it.

Step 3: Provide the Interceptor in your Standalone Application

In a standalone Angular application, you provide interceptors in your app.config.ts (or the configuration of the specific route/feature module where you want it active).

// src/app/app.config.ts
import { ApplicationConfig } from '@angular/core';
import { provideRouter } from '@angular/router';
import { routes } from './app.routes';
import { provideHttpClient, withInterceptors } from '@angular/common/http';
import { CacheInterceptor } from './core/interceptors/cache.interceptor'; // Import your interceptor

export const appConfig: ApplicationConfig = {
  providers: [
    provideRouter(routes),
    // Provide HttpClient with interceptors
    provideHttpClient(
      withInterceptors([
        CacheInterceptor // Register your CacheInterceptor here
      ])
    ),
    // CacheService is already providedIn: 'root', so no explicit provider needed here
  ]
};

Explanation:

provideHttpClient(withInterceptors([...])) is the modern way to register HttpInterceptors in standalone Angular applications. We simply list our CacheInterceptor in the array.

Step 4: Create a Sample Service and Component to Test

Let’s create a simple UserService and a component to demonstrate the caching and deduplication.

// src/app/users/user.service.ts
import { Injectable } from '@angular/core';
import { HttpClient } from '@angular/common/http';
import { Observable } from 'rxjs';

export interface User {
  id: number;
  name: string;
  email: string;
}

@Injectable({
  providedIn: 'root'
})
export class UserService {
  private apiUrl = 'https://jsonplaceholder.typicode.com/users'; // A public API for testing

  constructor(private http: HttpClient) {}

  getUsers(): Observable<User[]> {
    console.log('UserService: Fetching users...');
    // We can add custom headers here to control caching behavior
    // For example, to set a specific maxAge for this request:
    // return this.http.get<User[]>(this.apiUrl, { headers: { 'x-cache-max-age': '60000' } });
    return this.http.get<User[]>(this.apiUrl);
  }

  // Example of a modifying request that should invalidate the cache
  addUser(user: Partial<User>): Observable<User> {
    console.log('UserService: Adding user...');
    // The interceptor's non-GET logic should invalidate the /api/users cache
    return this.http.post<User>(this.apiUrl, user);
  }
}

Explanation:

UserService uses HttpClient to fetch a list of users from jsonplaceholder.typicode.com.
getUsers() is our cached method.
addUser() is a POST request, which our interceptor will recognize as a modifying operation and potentially trigger cache invalidation.

// src/app/users/user-list/user-list.component.ts
import { Component, OnInit } from '@angular/core';
import { CommonModule } from '@angular/common';
import { UserService, User } from '../user.service';
import { CacheService } from '../../core/services/cache.service'; // Import CacheService
import { Observable } from 'rxjs';

@Component({
  selector: 'app-user-list',
  standalone: true,
  imports: [CommonModule],
  template: `
    <h2>User List</h2>
    <div class="actions">
      <button (click)="loadUsers()">Load Users (Cached)</button>
      <button (click)="loadUsers(true)">Load Users (Skip Cache)</button>
      <button (click)="invalidateUsersCache()">Invalidate User Cache</button>
      <button (click)="addNewUser()">Add New User (Invalidates Cache)</button>
      <button (click)="clearAllCache()">Clear All Cache</button>
    </div>

    <div *ngIf="users$ | async as users">
      <p *ngIf="users.length === 0">No users found.</p>
      <ul>
        <li *ngFor="let user of users">{{ user.name }} ({{ user.email }})</li>
      </ul>
    </div>
    <div *ngIf="loading">Loading users...</div>
    <div *ngIf="error">Error loading users.</div>
  `,
  styles: [`
    .actions button { margin: 5px; padding: 10px 15px; cursor: pointer; }
    ul { list-style-type: none; padding: 0; }
    li { background: #f0f0f0; margin-bottom: 5px; padding: 8px; border-radius: 4px; }
  `]
})
export class UserListComponent implements OnInit {
  users$: Observable<User[]> | undefined;
  loading = false;
  error = false;

  constructor(private userService: UserService, private cacheService: CacheService) {}

  ngOnInit(): void {
    // Initial load
    this.loadUsers();
  }

  loadUsers(skipCache: boolean = false): void {
    this.loading = true;
    this.error = false;

    let headers: { [key: string]: string } = {};
    if (skipCache) {
      headers['x-skip-cache'] = 'true';
    }
    // You could also add 'x-cache-max-age': '60000' here for per-request TTL

    this.users$ = this.userService.getUsers().pipe(
      tap({
        next: () => { this.loading = false; },
        error: () => { this.loading = false; this.error = true; }
      })
    );
  }

  invalidateUsersCache(): void {
    // Invalidate the specific URL used by getUsers
    this.cacheService.invalidate('https://jsonplaceholder.typicode.com/users');
    console.log('Manually triggered user cache invalidation.');
    // Optionally reload users to see the effect
    this.loadUsers();
  }

  addNewUser(): void {
    this.loading = true;
    const newUser = { name: 'New User ' + Date.now(), email: 'newuser' + Date.now() + '@example.com' };
    this.userService.addUser(newUser).subscribe({
      next: (user) => {
        console.log('User added:', user);
        this.loading = false;
        // The interceptor should handle invalidation, but you could explicitly call it here too
        // this.cacheService.invalidate('https://jsonplaceholder.typicode.com/users');
        this.loadUsers(); // Reload users to see the updated list (after invalidation)
      },
      error: (err) => {
        console.error('Error adding user:', err);
        this.loading = false;
        this.error = true;
      }
    });
  }

  clearAllCache(): void {
    this.cacheService.clear();
    console.log('Manually cleared all cache.');
    this.loadUsers(); // Reload to fetch fresh data
  }
}

Explanation:

The UserListComponent uses UserService to fetch and display users.
loadUsers() method fetches users. It can optionally be told to skipCache by setting the x-skip-cache header.
invalidateUsersCache() and clearAllCache() demonstrate how to programmatically interact with the CacheService to manage cache state.
addNewUser() simulates a POST request. Observe how the interceptor invalidates the /api/users cache upon its completion, causing the subsequent loadUsers() call to fetch fresh data.

Step 5: Integrate into `app.component.ts`

Make sure your UserListComponent is used in your main application component.

// src/app/app.component.ts
import { Component } from '@angular/core';
import { RouterOutlet } from '@angular/router';
import { UserListComponent } from './users/user-list/user-list.component'; // Import your component

@Component({
  selector: 'app-root',
  standalone: true,
  imports: [RouterOutlet, UserListComponent], // Add UserListComponent here
  template: `
    <main>
      <h1>Angular Caching & Deduplication Demo</h1>
      <app-user-list></app-user-list>
    </main>
  `,
  styles: [],
})
export class AppComponent {
  title = 'angular-caching-demo';
}

To Run and Observe:

Save all the files.
Run your Angular application: ng serve.
Open your browser to http://localhost:4200 (or whatever port ng serve uses).
Open your browser’s developer console (F12) to the “Console” and “Network” tabs.
Observe Caching:
- Click “Load Users (Cached)”. You’ll see a network request (Status 200) and UserService: Fetching users... and Cached ... in the console.
- Click “Load Users (Cached)” again quickly. You should see Cache hit for ... in the console, but no new network request in the Network tab. This is your cache working!
- Wait for 30 seconds (default maxAge). Click “Load Users (Cached)” again. You should now see Cache expired for ... and a new network request.
Observe Deduplication:
- Click “Load Users (Cached)” rapidly multiple times (e.g., 5 clicks in 1 second). You should still only see one network request in the Network tab, and console logs showing New request pending... followed by Deduplicating request... for subsequent clicks.
Observe Invalidation:
- Click “Load Users (Cached)” to populate the cache.
- Click “Add New User”. This will make a POST request. Observe Invalidated cache for ... in the console.
- Then click “Load Users (Cached)” again. A new network request should be made because the cache was invalidated.
- Click “Load Users (Skip Cache)”. This should always make a new network request, bypassing the cache.

This hands-on experience will solidify your understanding of how these mechanisms work together.

Mini-Challenge: Tag-Based Cache Invalidation

Our current cache invalidation in CacheInterceptor is very basic (invalidating a single URL). For more complex applications, you might want to invalidate multiple related cache entries when a resource changes.

Challenge: Modify the CacheService and CacheInterceptor to support “tag-based” invalidation.

When caching a response, allow associating one or more “tags” with that cache entry (e.g., a list of users might have the tag ‘users’, a specific user might have tags ‘users’ and ‘user:{id}’).
Add a method invalidateByTag(tag: string) to CacheService.
In the CacheInterceptor, when a POST, PUT, or DELETE request is made, check for a custom header like x-invalidate-tags (e.g., x-invalidate-tags: users, user:123) and use it to invalidate all associated cache entries.

Hint:

Modify CacheEntry to include a tags: string[] property.
Modify put to accept tags.
When storing, you’ll need a way to map tags back to URLs (e.g., a Map<string, Set<string>> where key is tag and value is a set of URLs).
invalidateByTag would then look up all URLs associated with a tag and invalidate them using your existing invalidate(url) method.

What to observe/learn: This challenge will teach you about more granular control over cache invalidation, which is crucial for maintaining data consistency in larger applications. You’ll also deepen your understanding of Map data structures and how to design flexible caching APIs.

Common Pitfalls & Troubleshooting

Stale Data Issues:
- Pitfall: Data in the UI isn’t updating, even after a modification.
- Cause: Incorrect or missing cache invalidation logic. The cache thinks the data is still fresh when it’s not.
- Troubleshooting:
  - Check CacheInterceptor’s non-GET logic: Is it correctly identifying modifying requests and calling cacheService.invalidate() for the right URLs/tags?
  - Verify the maxAge for cached items. Is it too long for data that changes frequently?
  - Use console.log statements within CacheInterceptor and CacheService to trace cache hits, misses, and invalidations.
  - Inspect the cache Map directly in the debugger to see its contents and timestamps.
Cache Key Collisions:
- Pitfall: Different requests for similar data (e.g., /api/users?page=1 and /api/users?page=2) are treated as the same, leading to incorrect data being served.
- Cause: The cache key is not specific enough. Our current implementation uses request.urlWithParams, which is generally good, but subtle differences in query parameters or even header order (if you were to include headers in the key) could lead to issues.
- Troubleshooting:
  - Ensure request.urlWithParams is truly unique for distinct data sets. If requests differ only by headers (e.g., Accept-Language), you might need to include relevant headers in your cache key.
  - Always test edge cases with different query parameters, path variables, and request bodies.
Memory Leaks / Excessive Memory Usage:
- Pitfall: The application consumes more and more memory over time, eventually slowing down or crashing.
- Cause: Caching too many responses without proper eviction. Map objects grow indefinitely.
- Troubleshooting:
  - Ensure maxAge is set appropriately for all cached items. Don’t cache indefinitely unless absolutely necessary for static data.
  - Implement a “least recently used” (LRU) or “least frequently used” (LFU) eviction strategy for the cache if it’s expected to grow very large.
  - Regularly clear the cache (e.g., on user logout, or at certain application lifecycle events).
  - Use browser developer tools (Memory tab) to take heap snapshots and identify if your CacheService.cache map is growing uncontrollably.
  - The finalize operator in CacheInterceptor is critical for cleaning up pendingRequests to prevent leaks there.
Order of Interceptors:
- Pitfall: Caching/deduplication doesn’t work as expected, or interferes with other interceptors (e.g., authorization).
- Cause: The order in which interceptors are provided matters.
- Troubleshooting:
  - Ensure CacheInterceptor is placed appropriately in your withInterceptors array. For instance, if you have an AuthInterceptor that adds an Authorization header, the CacheInterceptor should generally come after it, so the cache key includes the header (if relevant) or the request is fully formed before caching decisions. If the AuthInterceptor modifies the request URL (e.g., for token refresh), consider the implications for caching the original URL.

Summary

Congratulations! You’ve successfully implemented sophisticated API caching and request deduplication in your Angular standalone application. Let’s recap the key takeaways:

Why it matters: Caching and deduplication are crucial for enhancing application performance, improving user experience by reducing loading times, and alleviating strain on your backend servers.
Core Concepts: We leveraged an in-memory cache with a Map and implemented time-based (TTL) invalidation, along with event-based invalidation for modifying requests.
Request Deduplication: Using shareReplay and a pendingRequests Map, we ensured that multiple concurrent requests for the same resource result in only one actual network call.
HttpInterceptor Power: Angular’s HttpInterceptor provides a clean, centralized way to implement these cross-cutting concerns, keeping your services and components focused on business logic.
CacheService: Abstracting cache management into a dedicated service allows for cleaner code and easier programmatic invalidation.
RxJS Operators: tap, of, shareReplay, and finalize were indispensable tools for building our interceptor logic.
Custom Headers: We saw how custom HTTP headers like x-skip-cache and x-cache-max-age can provide fine-grained control over caching behavior on a per-request basis.
Debugging: Always use console.log and browser developer tools to observe network requests, cache hits/misses, and memory usage.

By mastering these techniques, you’re well on your way to building highly performant and resilient Angular applications. In the next chapter, we’ll shift our focus to even more advanced HTTP patterns, exploring how to handle authorization headers, implement token refresh flows, and manage API errors effectively.

References

This page is AI-assisted and reviewed. It references official documentation and recognized resources where relevant.

Chapter 9: API Caching, Invalidation, and Request Deduplication

Table of Contents

Introduction

Why Cache? The Problem and the Solution

Request Deduplication: A Partner to Caching

Core Concepts for Client-Side Caching

Step-by-Step Implementation: Building a Smart Caching and Deduplication Interceptor

Step 1: Create the CacheService

Step 2: Create the CacheInterceptor

Step 3: Provide the Interceptor in your Standalone Application

Step 4: Create a Sample Service and Component to Test

Step 5: Integrate into app.component.ts

Mini-Challenge: Tag-Based Cache Invalidation

Common Pitfalls & Troubleshooting

Summary

References

Step 1: Create the `CacheService`

Step 2: Create the `CacheInterceptor`

Step 5: Integrate into `app.component.ts`