Frontend Data Fetching Patterns and Caching

Patterns for fetching, caching, and synchronizing server state in frontend applications. Covers request deduplication, cache invalidation strategies, stale-while-revalidate mechanics, and library implementations.

Abstract

Frontend data fetching reduces to managing three tensions: freshness vs latency (serve stale data immediately or wait for network?), correctness vs complexity (normalize cache for consistency or accept duplication?), and memory vs performance (cache everything or evict aggressively?).

The core patterns:

• Request deduplication: Multiple components requesting the same data share one in-flight promise—prevents duplicate network calls and ensures consistency
• Stale-while-revalidate: Return cached data instantly, revalidate in background—users see content immediately, fresh data arrives silently
• Cache normalization: Store entities once by ID, reference everywhere—mutations update all views automatically, but adds complexity
• Cache invalidation: Tag-based or key-based invalidation after mutations—the hardest problem, usually solved by refetching
• Garbage collection: Inactive queries evicted after configurable timeout—prevents memory leaks without manual cleanup

Libraries differ in their defaults: TanStack Query uses staleTime: 0 (always stale, always revalidate), SWR deduplicates within 1 second, Apollo normalizes by __typename:id, RTK Query uses tag-based invalidation without normalization.

HTTP Caching Fundamentals

Understanding HTTP caching is foundational—application-level caching builds on top of (or bypasses) browser cache behavior defined in RFC 9111.

Cache-Control Semantics

The Cache-Control header governs how browsers and intermediaries cache responses. Key directives from RFC 9111:

RFC 9111 replaced RFC 7234 in June 2022 with clarifications but no breaking changes. The stale-while-revalidate extension remains defined in RFC 5861.

Conditional Requests and Validation

When cached content is stale, browsers send conditional requests to check if the cached version is still valid:

1
Client: GET /api/users/123
2
        If-None-Match: "abc123"
3

4
Server: 304 Not Modified
5
        (no body, use cached version)
6

7
-- or --
8

9
Server: 200 OK
10
        ETag: "def456"
11
        (new body, update cache)

Validator types:

• Strong ETag ("abc123"): Byte-for-byte identical. Required for range requests.
• Weak ETag (W/"abc123"): Semantically equivalent. Allows minor variations (whitespace, formatting).
• Last-Modified: Timestamp-based. Less precise, 1-second resolution.

Design rationale: ETags exist because Last-Modified has 1-second resolution—multiple changes within a second produce identical timestamps. ETags use content hashes or version numbers for exact change detection.

Stale-While-Revalidate in HTTP

RFC 5861 defines the stale-while-revalidate Cache-Control extension:

1
Cache-Control: max-age=600, stale-while-revalidate=30

This means:

1. Response is fresh for 600 seconds
2. After 600s, serve stale content while revalidating in background
3. Stale serving allowed for up to 30 additional seconds
4. After 630s total, must wait for revalidation

Why this matters: The browser handles background revalidation automatically—no JavaScript required. However, application-level SWR (SWR library, TanStack Query) provides finer control and works with any response, not just those with proper headers.

Request Deduplication

Request deduplication ensures multiple components requesting the same data produce exactly one network request. Without it, a page with 5 components using useUser(123) would fire 5 identical API calls.

The Promise Memoization Pattern

The core pattern is simple: store the in-flight promise, return it to all callers:

4 collapsed lines
1
// Promise cache for in-flight requests
2
const inflightRequests = new Map<string, Promise<unknown>>()
3

4
// Deduplicated fetch function
5
async function fetchWithDeduplication<T>(key: string, fetcher: () => Promise<T>): Promise<T> {
6
  // Return existing promise if request in flight
7
  const existing = inflightRequests.get(key)
8
  if (existing) return existing as Promise<T>
9

10
  // Create new request and cache the promise
11
  const promise = fetcher().finally(() => {
12
    inflightRequests.delete(key) // Clean up after settlement
13
  })
14

15
  inflightRequests.set(key, promise)
16
  return promise
17
}

Key insight: The promise itself is cached, not the response. All callers await the same promise, so they all receive the result when it resolves—whether success or failure.

Library Implementations

TanStack Query (React Query v5):

• Deduplication is automatic and always-on for identical query keys
• Multiple hooks with the same key share one underlying promise
• No configurable deduplication window—requests dedupe while in-flight
• Option merging takes “most pessimistic” values when multiple components use different options (e.g., lowest staleTime)

SWR (Vercel):

• Default 1-second deduplication window via dedupingInterval
• Requests within the window share the same promise
• Window is configurable per-hook or globally
• Focused on “eventual consistency” over strict deduplication

1
// SWR global configuration
2
<SWRConfig value={{ dedupingInterval: 2000 }}>
3
  {/* Requests within 2 seconds share the same promise */}
4
</SWRConfig>

Apollo Client:

• Request deduplication at the transport layer (HttpLink)
• Additionally, normalized cache means fetching the same entity from different queries returns the same object reference
• Deduplication is opt-out via defaultOptions.watchQuery.fetchPolicy

RTK Query:

• Deduplication per endpoint + argument combination
• Cache entry created on first subscription, shared by subsequent ones
• Reference counting: cache entry kept while ≥1 subscriber exists

Edge Cases and Gotchas

Race conditions with mutations: If a mutation fires while a query is in-flight, the query result might be stale before it arrives. Libraries handle this differently:

• TanStack Query: invalidateQueries during mutation waits for in-flight queries to settle, then refetches
• SWR: mutate(key) cancels in-flight requests for that key
• Apollo: Mutation’s update function runs after mutation completes, before query refetch

Error propagation: All callers receive the same error when a deduplicated request fails. This is usually desirable—if the API is down, all components should know. But it means one component’s error boundary affects all components using the same data.

Deduplication scope: Most libraries deduplicate per-application instance. Server-side rendering creates a new query client per request to prevent data leaking between users.

Application-Level Caching

Application caches store fetched data in memory, separate from the browser’s HTTP cache. This enables instant UI updates, optimistic mutations, and fine-grained cache control.

Cache Architecture Patterns

Per-Query Cache (TanStack Query, SWR, RTK Query):

Each unique query key maps to one cache entry containing the response:

1
Cache Structure:
2
  ["users", 123] → { data: User, dataUpdatedAt: 1234567890 }
3
  ["users", 456] → { data: User, dataUpdatedAt: 1234567891 }
4
  ["posts", { authorId: 123 }] → { data: Post[], dataUpdatedAt: 1234567892 }

Trade-off: Simple to understand and implement. But if the same user appears in multiple queries, each query has its own copy. Updating user 123 in one query doesn’t automatically update it in others.

Normalized Cache (Apollo Client, Relay):

Entities stored once by ID, queries reference them:

1
Normalized Cache:
2
  User:123 → { id: 123, name: "Alice", email: "..." }
3
  User:456 → { id: 456, name: "Bob", email: "..." }
4
  ROOT_QUERY.users → [Reference(User:123), Reference(User:456)]
5
  ROOT_QUERY.posts({authorId:123}) → [Reference(Post:1), Reference(Post:2)]

Trade-off: Mutations automatically update all views of an entity—change User:123 once, every query referencing it reflects the change. But normalization adds complexity: custom keyFields for unique identification, merge functions for pagination, handling of cache inconsistencies.

Cache Invalidation Strategies

Cache invalidation is the hardest problem. The cache doesn’t know when server data changes unless told.

Time-based (TTL):

• Data considered stale after N seconds
• TanStack Query: staleTime (default 0—always stale)
• SWR: refreshInterval for polling
• Simple but imprecise—data might change immediately or not for hours

Mutation-based:

Invalidate related queries after mutations:

3 collapsed lines
1
const queryClient = useQueryClient()
2

3
const mutation = useMutation({
4
  mutationFn: updateUser,
5
  onSuccess: () => {
6
    // Invalidate and refetch all user queries
7
    queryClient.invalidateQueries({ queryKey: ["users"] })
8
    // Or be specific
9
    queryClient.invalidateQueries({ queryKey: ["users", userId] })
10
  },
11
})

Tag-based (RTK Query):

Queries declare what tags they provide; mutations declare what tags they invalidate:

6 collapsed lines
1
const api = createApi({
2
  baseQuery: fetchBaseQuery({ baseUrl: "/api" }),
3
  tagTypes: ["User", "Post"],
4
  endpoints: (builder) => ({
5
    getUsers: builder.query({
6
      query: () => "users",
7
      providesTags: (result) =>
8
        result ? [...result.map(({ id }) => ({ type: "User" as const, id })), "User"] : ["User"],
9
    }),
10
    updateUser: builder.mutation({
11
      query: ({ id, ...body }) => ({
12
        url: `users/${id}`,
13
        method: "PUT",
14
        body,
15
      }),
16
      invalidatesTags: (result, error, { id }) => [{ type: "User", id }],
17
    }),
18
  }),
19
})

Design rationale for tags: RTK Query chose tags over normalized cache because normalization is complex and error-prone. Tags provide explicit, predictable invalidation without the edge cases of automatic cache updates.

Garbage Collection

Without garbage collection, caches grow unbounded. Libraries implement automatic cleanup:

TanStack Query:

• gcTime (formerly cacheTime): Time inactive query stays in memory (default 5 minutes)
• Query becomes “inactive” when no components subscribe
• After gcTime, entry removed and next request refetches from network
• staleTime and gcTime are independent—long staleTime doesn’t extend gcTime

SWR:

• No explicit GC configuration
• Uses dedupingInterval and reference counting
• Cache entries cleaned when no active subscribers

Apollo Client:

• gc() method for manual garbage collection
• cache.evict({ id: 'User:123' }) for specific entries
• cache.gc() removes unreachable objects after eviction

Memory Limits and Constraints

Browser memory varies significantly:

Practical implications:

• Large normalized caches can exhaust mobile memory
• Profile cache size in production with performance.measureUserAgentSpecificMemory()
• Consider LRU eviction for high-volume applications
• SSR requires request-scoped caches to prevent cross-user data leaks

Stale-While-Revalidate Pattern

The stale-while-revalidate (SWR) pattern serves cached data immediately while fetching fresh data in the background. Users see content instantly; updates arrive silently.

Pattern Mechanics

Implementation Details

TanStack Query’s approach:

2 collapsed lines
1
const { data, isStale, isFetching } = useQuery({
2
  queryKey: ["users"],
3
  queryFn: fetchUsers,
4
  staleTime: 60_000, // Data fresh for 60 seconds
5
  refetchOnWindowFocus: true, // Revalidate when tab regains focus
6
  refetchOnMount: true, // Revalidate when component mounts
7
})
8

9
// isStale: true if past staleTime
10
// isFetching: true if background fetch in progress
11
// data: always the cached value (stale or fresh)

Revalidation triggers:

Why window focus matters: Users frequently switch tabs. When they return, cached data might be minutes old. Focus-triggered revalidation ensures they see current data without explicit refresh.

Optimistic Updates vs. SWR

SWR handles read consistency. Optimistic updates handle write latency:

5 collapsed lines
1
const queryClient = useQueryClient()
2

3
const mutation = useMutation({
4
  mutationFn: updateUser,
5
  // Optimistically update cache before mutation completes
6
  onMutate: async (newUser) => {
7
    // Cancel in-flight refetches
8
    await queryClient.cancelQueries({ queryKey: ["users", newUser.id] })
9

10
    // Snapshot current value for rollback
11
    const previousUser = queryClient.getQueryData(["users", newUser.id])
12

13
    // Optimistically update
14
    queryClient.setQueryData(["users", newUser.id], newUser)
15

16
    return { previousUser }
17
  },
18
  // Rollback on error
19
  onError: (err, newUser, context) => {
20
    queryClient.setQueryData(["users", newUser.id], context?.previousUser)
21
  },
22
  // Refetch after success to ensure consistency
23
  onSettled: () => {
24
    queryClient.invalidateQueries({ queryKey: ["users"] })
25
  },
26
})

Design trade-off: Optimistic updates make UI feel instant but require rollback logic. Some teams prefer waiting for mutation success—simpler code, slightly slower perceived performance.

Pagination Patterns

Pagination affects both API design and cache structure. The choice between cursor and offset pagination has significant performance implications.

Cursor vs. Offset Pagination

Offset pagination:

1
GET /api/posts?offset=100&limit=20

• Skip first N records, return next M
• Familiar UX: “Page 1, 2, 3…”
• Performance degrades with offset: Database must scan and discard first N rows
• Consistency issues: Insert/delete between pages causes duplicates or gaps

Cursor pagination:

1
GET /api/posts?cursor=eyJpZCI6MTIzfQ&limit=20

• Opaque pointer to position in dataset
• O(1) performance: Database seeks directly to cursor position
• Consistent: Insertions/deletions don’t affect pagination
• Trade-off: No “jump to page 50” capability

Performance comparison (real-world benchmarks):

Cursor pagination maintains ~5ms regardless of position.

Infinite Scroll Implementation

5 collapsed lines
1
import { useInfiniteQuery } from '@tanstack/react-query'
2

3
function useInfinitePosts() {
4
  return useInfiniteQuery({
5
    queryKey: ['posts'],
6
    queryFn: ({ pageParam }) => fetchPosts({ cursor: pageParam }),
7
    initialPageParam: undefined,
8
    getNextPageParam: (lastPage) => lastPage.nextCursor,
9
    getPreviousPageParam: (firstPage) => firstPage.prevCursor,
10
  })
11
}
12

13
// Usage with intersection observer for infinite scroll
14
function PostList() {
15
  const { data, fetchNextPage, hasNextPage, isFetchingNextPage } =
16
    useInfinitePosts()
17

18
  const loadMoreRef = useIntersectionObserver(() => {
19
    if (hasNextPage && !isFetchingNextPage) {
20
      fetchNextPage()
21
    }
22
  })
23

24
  return (
6 collapsed lines
25
    <>
26
      {data?.pages.flatMap((page) => page.posts.map((post) => <Post key={post.id} post={post} />))}
27
      <div ref={loadMoreRef} />
28
    </>
29
  )
30
}

Cache Structure for Paginated Data

TanStack Query: Pages stored as array in single cache entry:

1
["posts"] → {
2
  pages: [
3
    { posts: [...], nextCursor: "abc" },
4
    { posts: [...], nextCursor: "def" },
5
    { posts: [...], nextCursor: null }
6
  ],
7
  pageParams: [undefined, "abc", "def"]
8
}

Apollo Client: Requires custom merge function for pagination:

8 collapsed lines
1
const cache = new InMemoryCache({
2
  typePolicies: {
3
    Query: {
4
      fields: {
5
        posts: {
6
          keyArgs: ["authorId"], // Different cache entries per author
7
          merge(existing = { edges: [] }, incoming) {
8
            return {
9
              ...incoming,
10
              edges: [...existing.edges, ...incoming.edges],
11
            }
12
          },
13
        },
14
      },
15
    },
16
  },
17
})

Prefetching Next Page

Prefetch the next page before users reach the end:

4 collapsed lines
1
const queryClient = useQueryClient()
2

3
// Prefetch when user is N items from the end
4
function usePrefetchNextPage(currentCursor: string, threshold = 5) {
5
  useEffect(() => {
6
    queryClient.prefetchInfiniteQuery({
7
      queryKey: ["posts"],
8
      queryFn: ({ pageParam }) => fetchPosts({ cursor: pageParam }),
9
      initialPageParam: currentCursor,
10
    })
11
  }, [currentCursor])
12
}

Error Handling and Retries

Network requests fail. Robust data fetching requires systematic error handling and intelligent retry strategies.

Retry Strategies

Exponential backoff with jitter (AWS recommended pattern):

1
function calculateBackoff(attempt: number, baseDelay = 1000, maxDelay = 30000): number {
2
  // Exponential: 1s, 2s, 4s, 8s, 16s...
3
  const exponentialDelay = baseDelay * Math.pow(2, attempt)
4
  // Cap at maximum
5
  const cappedDelay = Math.min(exponentialDelay, maxDelay)
6
  // Add jitter (0-100% of delay) to prevent thundering herd
7
  const jitter = Math.random() * cappedDelay
8
  return cappedDelay + jitter
9
}

Why jitter matters: Without jitter, all clients retry at the same time after an outage, overwhelming the recovering server. Jitter spreads retries over time.

Library defaults:

Retryable vs. Non-Retryable Errors

Not all errors should trigger retries:

3 collapsed lines
1
const { data } = useQuery({
2
  queryKey: ["users"],
3
  queryFn: fetchUsers,
4
  retry: (failureCount, error) => {
5
    // Don't retry client errors
6
    if (error.status >= 400 && error.status < 500) {
7
      return false
8
    }
9
    // Retry server errors up to 3 times
10
    return failureCount < 3
11
  },
12
  retryDelay: (attemptIndex) => Math.min(1000 * 2 ** attemptIndex, 30000),
13
})

Idempotency for Safe Retries

Retrying non-idempotent requests (POST, PATCH) risks duplicate side effects. The Idempotency-Key header (IETF draft) solves this:

4 collapsed lines
1
async function createPayment(amount: number) {
2
  const idempotencyKey = crypto.randomUUID()
3

4
  const response = await fetch("/api/payments", {
5
    method: "POST",
6
    headers: {
7
      "Content-Type": "application/json",
8
      "Idempotency-Key": idempotencyKey,
9
    },
10
    body: JSON.stringify({ amount }),
11
  })
12

13
  return response.json()
14
}

How it works:

1. Client generates unique key for each logical operation
2. Server stores key → response mapping
3. If request retried with same key, server returns stored response
4. Prevents duplicate charges, duplicate orders, etc.

Widely supported: Stripe, Adyen, and most payment gateways require idempotency keys for mutations.

Circuit Breaker Pattern

Prevent cascading failures when a service is down:

5 collapsed lines
1
class CircuitBreaker {
2
  private failures = 0
3
  private lastFailure: number | null = null
4
  private state: "closed" | "open" | "half-open" = "closed"
5

6
  constructor(
7
    private threshold = 5,
8
    private timeout = 30000,
9
  ) {}
10

11
  async execute<T>(fn: () => Promise<T>): Promise<T> {
12
    if (this.state === "open") {
13
      if (Date.now() - (this.lastFailure ?? 0) > this.timeout) {
14
        this.state = "half-open"
15
      } else {
16
        throw new Error("Circuit breaker is open")
17
      }
18
    }
19

20
    try {
21
      const result = await fn()
22
      this.onSuccess()
23
      return result
24
    } catch (error) {
25
      this.onFailure()
26
      throw error
27
    }
28
  }
29

30
  private onSuccess() {
31
    this.failures = 0
32
    this.state = "closed"
33
  }
34

8 collapsed lines
35
  private onFailure() {
36
    this.failures++
37
    this.lastFailure = Date.now()
38
    if (this.failures >= this.threshold) {
39
      this.state = "open"
40
    }
41
  }
42
}

States:

• Closed: Normal operation, requests pass through
• Open: After N failures, fail immediately without network call
• Half-Open: After timeout, allow one test request

Library Comparison

TanStack Query (React Query v5)

Architecture: Per-query cache with automatic garbage collection.

Key concepts:

• staleTime: How long data considered fresh (default: 0)
• gcTime: How long inactive queries stay in cache (default: 5 minutes)
• Query keys: Array-based, supports complex objects
• Devtools: Excellent built-in debugging

Strengths: Intuitive API, great TypeScript support, framework-agnostic (React, Vue, Solid, Svelte).

Limitations: No normalized cache—same entity in different queries = different copies.

Version note: v5 (released 2023) renamed cacheTime to gcTime for clarity. The v4 → v5 migration requires updating this option name.

SWR (Vercel)

Architecture: Minimal, focused on stale-while-revalidate pattern.

Key concepts:

• dedupingInterval: Deduplication window (default: 2 seconds)
• refreshInterval: Polling interval
• Focus/reconnect revalidation by default
• Optimized for 60% fewer re-renders via selective state updates

Strengths: Tiny bundle (~4KB), simple API, good defaults for most cases.

Limitations: Less powerful than TanStack Query for complex scenarios (pagination, optimistic updates).

Apollo Client

Architecture: Normalized cache with GraphQL-specific optimizations.

Key concepts:

• InMemoryCache: Flattened object store keyed by __typename:id
• TypePolicies: Custom cache behavior per type
• fetchPolicy: Controls cache vs. network priority
• Automatic cache updates after mutations

Strengths: Automatic consistency via normalization, powerful for GraphQL.

Limitations: GraphQL-specific, normalized cache complexity, larger bundle.

Cache normalization example:

5 collapsed lines
1
const cache = new InMemoryCache({
2
  typePolicies: {
3
    User: {
4
      // Use email as unique identifier instead of id
5
      keyFields: ["email"],
6
    },
7
    Product: {
8
      fields: {
9
        // Compute displayPrice from cached price
10
        displayPrice: {
11
          read(_, { readField }) {
12
            const price = readField<number>("price")
13
            return price ? `$${price.toFixed(2)}` : null
14
          },
15
        },
16
      },
17
    },
18
  },
19
})

RTK Query

Architecture: Built on Redux Toolkit, tag-based cache invalidation.

Key concepts:

• providesTags: What data a query provides
• invalidatesTags: What tags a mutation invalidates
• Automatic refetch when tags invalidate
• Per-endpoint cache configuration

Strengths: Great for Redux apps, explicit invalidation logic, good TypeScript inference.

Limitations: Redux dependency, no normalized cache, more boilerplate than alternatives.

Decision Matrix

Conclusion

Frontend data fetching is a solved problem at the library level—TanStack Query, SWR, Apollo, and RTK Query handle the hard parts. The challenge is choosing the right tool and understanding its trade-offs.

Key decisions:

1. Normalized vs. per-query cache: Normalized (Apollo) guarantees consistency but adds complexity. Per-query (TanStack Query, SWR) is simpler but requires manual invalidation.

2. Stale time configuration: staleTime: 0 (TanStack Query default) means constant background refetching. Increase it for data that changes rarely. Balance freshness against network cost.

3. Pagination strategy: Cursor pagination performs better at scale. Offset is acceptable for small datasets with jump-to-page requirements.

4. Error handling: Retry transient errors with exponential backoff and jitter. Use idempotency keys for mutations. Circuit breakers prevent cascading failures.

The common mistake is over-engineering: reaching for normalized caching when per-query suffices, implementing complex optimistic updates when showing a loading spinner is acceptable, or building custom solutions when libraries handle it better.

Appendix

Prerequisites

• Understanding of HTTP caching headers (Cache-Control, ETag)
• Familiarity with Promises and async/await
• Basic knowledge of React hooks (for library examples)
• Understanding of REST API pagination concepts

Terminology

• Stale data: Cached data past its configured freshness time, still usable but should be revalidated
• GC (Garbage Collection): Automatic removal of unused cache entries to free memory
• Normalized cache: Cache structure where entities are stored once by ID and referenced from multiple queries
• Deduplication: Combining multiple identical requests into a single network call
• Idempotent: Operation that produces the same result regardless of how many times it’s executed
• Circuit breaker: Pattern that fails fast when a service is known to be down, preventing wasted requests

Summary

• HTTP caching (RFC 9111, RFC 5861) provides browser-level caching with Cache-Control, conditional requests via ETags, and stale-while-revalidate for background refresh
• Request deduplication stores in-flight promises—multiple components with the same query key share one network request
• Application caching stores responses in memory; per-query cache is simpler, normalized cache ensures consistency
• Cache invalidation strategies: time-based (TTL), mutation-based (invalidate after write), tag-based (RTK Query’s explicit dependency tracking)
• Stale-while-revalidate serves cached data immediately, revalidates in background—configurable via staleTime and revalidation triggers
• Cursor pagination outperforms offset at scale (O(1) vs O(N)); use offset only for small datasets with page-number requirements
• Retry strategies: exponential backoff with jitter for transient errors, idempotency keys for safe mutation retries, circuit breakers for cascading failure prevention

References

Specifications

• RFC 9111 - HTTP Caching - Authoritative HTTP cache semantics (replaced RFC 7234)
• RFC 5861 - HTTP Cache-Control Extensions - stale-while-revalidate and stale-if-error extensions
• RFC 9110 - HTTP Semantics - Idempotent method definitions (GET, PUT, DELETE)
• IETF Draft - Idempotency-Key Header - Standardized idempotency key format

Official Documentation

• TanStack Query Documentation - Query concepts, caching, and mutations
• SWR Documentation - Performance optimizations and configuration
• Apollo Client Cache Configuration - Normalized cache and type policies
• RTK Query Overview - Tag-based invalidation and cache behavior

Implementation References

• AWS Builders Library - Timeouts, Retries, and Backoff - Exponential backoff with jitter patterns
• MDN - HTTP Caching - Browser caching behavior
• MDN - HTTP Conditional Requests - ETag and Last-Modified validation