Introduction
In modern web applications, the tension between performance and data freshness represents one of the most challenging trade-offs engineers face. Serve stale cached content, and users might act on outdated information. Always fetch fresh data, and you sacrifice the performance gains that make caching valuable in the first place. The stale-while-revalidate (SWR) caching pattern offers an elegant solution to this dilemma by allowing systems to serve cached content immediately while asynchronously fetching fresh data in the background.
Stale-while-revalidate originated as an HTTP Cache-Control extension documented in RFC 5861, but its principles have expanded far beyond HTTP headers. Today, SWR influences everything from CDN configurations to client-side data fetching libraries. This pattern has become particularly relevant as applications increasingly prioritize perceived performance and user experience metrics like First Contentful Paint and Time to Interactive. Understanding SWR is essential for engineers building systems that need to balance consistency, availability, and performance—the classic distributed systems challenge that affects everything from content delivery networks to React applications.
The name itself describes the mechanism: serve stale content from cache while simultaneously revalidating that content in the background. This approach ensures users never wait for network requests while guarantees eventual consistency. For many use cases—product catalogs, social media feeds, news articles, and analytics dashboards—this represents the optimal balance between speed and accuracy.
Understanding the Problem: The Cache Freshness Dilemma
Traditional caching strategies force engineers into a binary choice. With a strict time-to-live (TTL) approach, cached content remains valid for a predetermined period, then expires completely. When a request arrives after expiration, the cache cannot serve the content, forcing the user to wait for a fresh fetch from the origin. This creates predictable performance degradation at TTL boundaries—exactly when cache hit rates drop to zero and all requests become cache misses. For high-traffic applications, these moments create origin server load spikes that can cascade into availability issues.
The alternative—serving perpetually stale cache with long TTLs—improves performance consistency but introduces data accuracy problems. Users might see outdated prices, deprecated features, or incorrect inventory levels. For certain domains like financial data, medical information, or real-time collaboration tools, this staleness becomes unacceptable. The fundamental issue is that traditional caching treats freshness as a binary state: content is either valid or invalid, fresh or stale, usable or expired.
This binary model fails to acknowledge a crucial reality: for many applications, slightly stale data is infinitely better than no data, especially when fresh data is already being fetched. Consider an e-commerce product page. If your cache expires and the origin server takes 800ms to respond, should the user stare at a blank screen or spinner? Or should they see the product details from 30 seconds ago while fresh data loads invisibly in the background? For most use cases, the latter provides superior user experience.
The cache freshness dilemma becomes even more complex in distributed systems. CDNs with hundreds of edge locations each maintain independent caches. When content expires simultaneously across all edge nodes, the resulting thundering herd of requests to the origin can overwhelm backend systems. Engineers often address this with cache stampede prevention techniques, but these add complexity and still don't solve the user experience problem of waiting for fresh fetches.
How Stale-While-Revalidate Works
The stale-while-revalidate pattern introduces a two-stage cache lifecycle that decouples content validity from content usability. Instead of a single TTL value, SWR uses two distinct time windows. The first window, controlled by the standard max-age directive, defines how long content is considered fresh. During this period, the cache serves content immediately with no revalidation. The second window, controlled by stale-while-revalidate, defines an additional grace period during which stale content can be served while revalidation occurs asynchronously in the background.
Here's how the lifecycle works in practice. When content first enters the cache with a Cache-Control: max-age=60, stale-while-revalidate=300 header, it remains fresh for 60 seconds. Requests during this period receive instant cache hits with no origin communication. After 60 seconds elapse, the content enters the stale-but-revalidating window. The next request triggers two simultaneous actions: the cache immediately returns the stale content to the client, while also initiating an asynchronous background request to the origin for fresh content. Crucially, the user doesn't wait for this revalidation. Once the background request completes, the cache updates with fresh content and resets the timers.
// Example HTTP response with SWR headers
HTTP/1.1 200 OK
Cache-Control: max-age=60, stale-while-revalidate=300
Content-Type: application/json
Date: Thu, 19 Mar 2026 10:00:00 GMT
{
"product": {
"id": "12345",
"price": 29.99,
"inventory": 47
}
}
// Timeline of cache behavior:
// 0-60s: Serve from cache (fresh)
// 60-360s: Serve from cache immediately + revalidate in background (stale)
// 360s+: Must revalidate before serving (expired)
The pattern's power lies in its ability to provide both immediate response times and eventual data freshness. The first user to hit stale cache experiences the same fast response as if content were still fresh—they receive stale data instantly. Simultaneously, that request triggers revalidation, meaning the second user gets fresh content, also instantly. The system maintains high cache hit rates even after the max-age period expires, because stale content remains useful during revalidation.
This mechanism also provides natural protection against origin failures. If the background revalidation request fails due to origin unavailability, the cache can continue serving stale content rather than propagating errors to users. This graceful degradation makes systems more resilient. Some implementations extend this with stale-if-error directives, explicitly allowing stale content when origins return error status codes, further improving availability during incidents.
Alternatives to Stale-While-Revalidate
Understanding SWR requires context about alternative caching strategies and when each pattern excels. The most basic alternative is simple time-based expiration with no stale serving. Content has a fixed TTL, and after expiration, every request blocks until fresh content arrives from the origin. This pattern works well for low-traffic applications where cache coordination complexity outweighs benefits, or for data where staleness is completely unacceptable—think authentication tokens or real-time auction bids. The implementation simplicity is attractive, but it doesn't scale well under load or provide good user experience during cache misses.
Conditional validation using ETags and Last-Modified headers represents another common pattern. Here, the cache stores content along with a validation token. When content expires, the cache makes a conditional request to the origin with If-None-Match or If-Modified-Since headers. If content hasn't changed, the origin returns a 304 Not Modified response with no body, allowing the cache to refresh its TTL without transferring the full resource again. This reduces bandwidth compared to full re-fetches but still requires users to wait for the validation round-trip. For large resources over high-latency connections, this saves significant bandwidth while still incurring latency costs.
// Conditional validation approach
// Initial response
HTTP/1.1 200 OK
Cache-Control: max-age=60, must-revalidate
ETag: "v123-abc"
Content-Length: 45000
// After expiration, conditional request
GET /api/product/12345 HTTP/1.1
If-None-Match: "v123-abc"
// If unchanged, lightweight response
HTTP/1.1 304 Not Modified
ETag: "v123-abc"
Cache-Control: max-age=60, must-revalidate
// Cache extends TTL without re-downloading content
Cache-aside (lazy loading) patterns common in application-level caching take a different approach. The application checks the cache first; on a miss, it fetches from the source, stores the result, and returns it. This pattern gives applications complete control over cache invalidation and freshness logic. Libraries like Redis or Memcached commonly implement this pattern. The downside is that cache misses directly impact user-facing latency, and applications must handle cache stampede scenarios where many simultaneous requests for the same missing key all hit the origin.
Time-based cache invalidation with background refresh represents perhaps the closest alternative to SWR. Systems proactively refresh cached content before expiration using background jobs or timers. This ensures cache always contains relatively fresh content, but requires careful orchestration to avoid wasting resources refreshing rarely-accessed content. SWR's request-driven revalidation naturally optimizes for access patterns—only content that users actually request gets revalidated, while rarely-accessed content expires without wasting origin capacity.
Event-driven cache invalidation, where updates to source data trigger immediate cache purges or updates, provides the strongest freshness guarantees but requires tight coupling between data sources and caches. When a product price changes in the database, the system immediately invalidates or updates all cached representations of that product. This works excellently in microservices architectures with event buses but adds significant implementation complexity and potential failure modes. SWR offers a pragmatic middle ground: accept bounded staleness in exchange for architectural simplicity and operational resilience.
Implementing SWR in AWS CloudFront
AWS CloudFront, Amazon's content delivery network, provides robust support for stale-while-revalidate semantics through Cache-Control header interpretation and custom cache behaviors. Implementing SWR in CloudFront requires coordination between your origin server's response headers and CloudFront's cache configuration. The origin controls caching directives via Cache-Control headers, while CloudFront distributions define policies that govern how to interpret and respect those directives.
The most straightforward implementation involves configuring your origin to emit appropriate Cache-Control headers and ensuring CloudFront respects them. Start by creating a cache policy that enables origin header-based caching. In the CloudFront console or via Infrastructure as Code tools like CloudFormation or Terraform, create a cache policy with cache directive settings that respect Cache-Control headers. The critical configuration is ensuring CloudFront honors both max-age and stale-while-revalidate directives from your origin.
// Origin server response configuration (Express.js example)
app.get('/api/products/:id', async (req, res) => {
const product = await database.getProduct(req.params.id);
// Set SWR cache headers
res.set({
'Cache-Control': 'public, max-age=300, stale-while-revalidate=3600',
'Content-Type': 'application/json'
});
res.json(product);
});
// This tells CloudFront:
// - Treat content as fresh for 5 minutes (300s)
// - After 5 minutes, serve stale for up to 1 hour while revalidating
// - After 1 hour 5 minutes total, content is fully expired
CloudFront's implementation of stale-while-revalidate follows the RFC 5861 specification. When CloudFront edge locations receive a request for stale content within the stale-while-revalidate window, they return the stale object to the viewer immediately while simultaneously making an asynchronous request to the origin for fresh content. This background request updates the edge cache without blocking the user's request. If the origin request fails, CloudFront continues serving stale content, providing graceful degradation during origin outages.
For production deployments, consider using CloudFront Origin Shield in conjunction with SWR. Origin Shield adds an additional caching layer between CloudFront edge locations and your origin, centralizing origin requests and dramatically reducing origin load. When combined with stale-while-revalidate, Origin Shield ensures that background revalidation requests are deduplicated—even if multiple edge locations need revalidation simultaneously, only one request reaches your origin. This amplifies SWR's benefits for high-traffic global applications.
// CloudFormation template for CloudFront distribution with SWR
Resources:
ProductAPICache:
Type: AWS::CloudFront::CachePolicy
Properties:
CachePolicyConfig:
Name: ProductAPISWRPolicy
DefaultTTL: 300
MaxTTL: 3900 # max-age + stale-while-revalidate
MinTTL: 0
ParametersInCacheKeyAndForwardedToOrigin:
EnableAcceptEncodingGzip: true
HeadersConfig:
HeaderBehavior: none
CookiesConfig:
CookieBehavior: none
QueryStringsConfig:
QueryStringBehavior: all
Distribution:
Type: AWS::CloudFront::Distribution
Properties:
DistributionConfig:
Origins:
- Id: ProductAPIOrigin
DomainName: api.example.com
OriginShield:
Enabled: true
OriginShieldRegion: us-east-1
DefaultCacheBehavior:
TargetOriginId: ProductAPIOrigin
CachePolicyId: !Ref ProductAPICache
ViewerProtocolPolicy: redirect-to-https
Monitor your SWR implementation using CloudFront metrics and logs. Key metrics include cache hit rate, origin requests, and error rates. A properly configured SWR implementation should maintain high cache hit rates even during content updates, with minimal origin request spikes. CloudFront real-time logs provide detailed visibility into cache behavior, including cache status (Hit, RefreshHit, Miss) that helps you understand how often stale-while-revalidate activates.
Client-Side SWR Implementation
While HTTP-level stale-while-revalidate provides excellent CDN and browser caching, client-side JavaScript applications often need similar patterns for dynamic data fetching. The SWR library created by Vercel (originally for Next.js but framework-agnostic) implements stale-while-revalidate semantics for React applications, managing local state and background refetching with an elegant API. This library has influenced similar patterns in TanStack Query (formerly React Query), Apollo Client, and other data fetching solutions.
The client-side SWR pattern extends beyond simple HTTP caching by integrating with application state management, providing deduplication, focus revalidation, and network status awareness. When multiple components request the same data, SWR deduplicates the requests and shares the response. When users return to a tab after switching away, SWR automatically revalidates to catch any changes that occurred while they were away. These behaviors create a responsive experience that feels real-time while minimizing network overhead.
// Using the SWR library in a React component
import useSWR from 'swr';
interface Product {
id: string;
name: string;
price: number;
inventory: number;
}
// Fetcher function that SWR will call
const fetcher = (url: string) =>
fetch(url).then(res => res.json());
function ProductDetail({ productId }: { productId: string }) {
const { data, error, isLoading, isValidating } = useSWR<Product>(
`/api/products/${productId}`,
fetcher,
{
// Revalidate when window regains focus
revalidateOnFocus: true,
// Revalidate when network reconnects
revalidateOnReconnect: true,
// Cache data for 5 minutes
dedupingInterval: 300000,
// Keep showing previous data during revalidation
keepPreviousData: true
}
);
if (error) {
return <ErrorDisplay error={error} />;
}
// Show stale data while revalidating
return (
<div>
{isValidating && <RevalidatingIndicator />}
<ProductCard
product={data}
loading={isLoading}
/>
</div>
);
}
The power of client-side SWR lies in its optimistic UI patterns. The library returns previously cached data immediately (the "stale" part) while triggering a background revalidation request. Users see content instantly, with subtle indicators showing that fresher data is loading. This creates perceived performance that significantly exceeds traditional loading spinner approaches. For applications with frequent data updates—dashboards, social feeds, collaborative tools—this pattern dramatically improves user experience.
Implementing custom SWR logic without a library is instructive for understanding the pattern's mechanics. The core algorithm maintains an in-memory cache keyed by request parameters, tracks request timestamps, and manages background refetch logic. Below is a simplified implementation that demonstrates the essential concepts:
type CacheEntry<T> = {
data: T;
timestamp: number;
promise?: Promise<T>;
};
class SWRCache {
private cache = new Map<string, CacheEntry<any>>();
private maxAge: number; // Fresh window in milliseconds
private staleWhileRevalidate: number; // Stale window
constructor(maxAge = 60000, staleWhileRevalidate = 300000) {
this.maxAge = maxAge;
this.staleWhileRevalidate = staleWhileRevalidate;
}
async fetch<T>(
key: string,
fetcher: () => Promise<T>
): Promise<T> {
const now = Date.now();
const cached = this.cache.get(key);
// No cache entry - fetch and wait
if (!cached) {
return this.fetchAndCache(key, fetcher);
}
const age = now - cached.timestamp;
// Fresh cache - return immediately
if (age < this.maxAge) {
return cached.data;
}
// Stale but within revalidation window
if (age < this.maxAge + this.staleWhileRevalidate) {
// Return stale data immediately
// Trigger background revalidation if not already in progress
if (!cached.promise) {
this.revalidateInBackground(key, fetcher);
}
return cached.data;
}
// Expired - must revalidate before returning
return this.fetchAndCache(key, fetcher);
}
private async fetchAndCache<T>(
key: string,
fetcher: () => Promise<T>
): Promise<T> {
const promise = fetcher();
// Store the promise to deduplicate concurrent requests
const entry = this.cache.get(key);
if (entry) {
entry.promise = promise;
}
try {
const data = await promise;
this.cache.set(key, {
data,
timestamp: Date.now(),
promise: undefined
});
return data;
} catch (error) {
// On error, keep serving stale data if available
if (entry?.data) {
return entry.data;
}
throw error;
}
}
private revalidateInBackground<T>(
key: string,
fetcher: () => Promise<T>
): void {
// Don't await - let this run in background
this.fetchAndCache(key, fetcher).catch(error => {
console.warn('Background revalidation failed:', error);
// Stale data remains in cache
});
}
}
// Usage
const cache = new SWRCache(5000, 30000); // 5s fresh, 30s stale
async function getProduct(id: string) {
return cache.fetch(
`product-${id}`,
() => fetch(`/api/products/${id}`).then(r => r.json())
);
}
This implementation demonstrates key SWR concepts: separating fresh and stale time windows, returning stale data synchronously while revalidating asynchronously, request deduplication via promise caching, and graceful error handling that prefers stale data over failures. Production libraries add sophisticated features like cache size management, mutation support, optimistic updates, and React integration, but the core pattern remains the same.
Trade-offs and Pitfalls
Stale-while-revalidate is not a universal solution, and understanding its limitations is crucial for appropriate application. The pattern's fundamental trade-off is accepting bounded staleness in exchange for performance and availability. This works excellently for eventually consistent data—content where brief staleness is acceptable—but fails for strongly consistent requirements. Financial transactions, inventory reservations, authentication states, and other scenarios requiring read-after-write consistency need different approaches. Serving stale account balances or product availability could lead to failed transactions or poor user experiences.
The staleness window requires careful tuning based on your data's characteristics and business requirements. Set stale-while-revalidate too short, and you lose the pattern's benefits—content expires before background revalidation can complete, forcing users to wait. Set it too long, and users might see egregiously outdated content during origin outages or network issues. For e-commerce product descriptions, a 10-minute stale window might be perfectly acceptable. For stock prices or sports scores, even 30 seconds might be too long. There's no one-size-fits-all value; you must consider data volatility, user expectations, and business impact.
Cache invalidation complexity increases with SWR, particularly in multi-tier caching architectures. When you update data at the origin, that change won't immediately propagate to all caches—it only propagates when each cache's revalidation occurs. If you have a CDN edge cache with SWR, a browser cache with SWR, and client-side state with SWR, updates might take several minutes to fully propagate through all layers. For some applications, this eventual consistency is fine. For others, you need explicit cache purging or invalidation mechanisms, which adds operational complexity and potential failure modes.
// Pitfall: Cascading staleness across cache tiers
// User's browser cache: max-age=60, stale-while-revalidate=600
// CloudFront edge: max-age=300, stale-while-revalidate=3600
// Origin Shield: max-age=60, stale-while-revalidate=300
// In worst case, user might see data up to:
// 60s (browser fresh) + 600s (browser stale) +
// 300s (CF fresh) + 3600s (CF stale) = 4560s (76 minutes) old!
// Better approach: Align TTLs or use explicit invalidation
// Browser: max-age=60, stale-while-revalidate=120
// CloudFront: max-age=60, stale-while-revalidate=300
// Maximum staleness: 60 + 120 = 180s (3 minutes)
Background revalidation creates additional origin load that might surprise teams transitioning from simpler caching strategies. With traditional TTL-based caching, origin receives requests only on cache misses. With SWR, origin receives revalidation requests for every access during the stale window. For high-traffic content, this can mean continuous origin load even with high cache hit rates. Monitor origin request patterns carefully when implementing SWR, and ensure your infrastructure can handle the additional background requests. Origin Shield and request collapsing help mitigate this, but the load increase is inherent to the pattern.
Error handling during revalidation requires thoughtful implementation. When background revalidation fails—origin is down, network issues, or application errors—caches must decide whether to continue serving stale content or propagate errors. Most implementations wisely choose to serve stale data during origin failures, improving availability. However, this can mask ongoing production issues. If your origin is completely broken but caches continue serving stale content, users might not report problems immediately, delaying your incident response. Implement robust monitoring and alerting for background revalidation failures to catch issues proactively.
Best Practices
Successful SWR implementation starts with understanding your data's characteristics and access patterns. Categorize content by update frequency, staleness tolerance, and traffic patterns. Static assets like images or compiled JavaScript can use aggressive caching with long stale windows. Dynamic data like user profiles might need shorter fresh windows but still benefit from SWR. Real-time data might not be suitable for SWR at all. Create a content classification system and apply appropriate caching policies to each category rather than using one-size-fits-all configurations.
Implement comprehensive cache observability to understand how SWR performs in production. Track metrics beyond simple hit rates: measure revalidation request volume, background request failure rates, and actual staleness experienced by users. CloudFront cache status codes (Hit, RefreshHit, Miss) provide valuable insights into cache behavior. For client-side implementations, instrument your SWR library to track revalidation frequency and error rates. This telemetry helps you tune TTL values and identify pathological cases where revalidation occurs too frequently or stale content persists too long.
// Instrumented SWR configuration with observability
import useSWR from 'swr';
import { metrics } from './monitoring';
function useInstrumentedSWR<T>(key: string, fetcher: () => Promise<T>) {
const startTime = Date.now();
const result = useSWR<T>(key, fetcher, {
onSuccess: (data) => {
metrics.increment('swr.success', { key });
metrics.histogram('swr.latency', Date.now() - startTime, { key });
},
onError: (error) => {
metrics.increment('swr.error', { key, error: error.message });
},
onLoadingSlow: () => {
metrics.increment('swr.slow', { key });
},
// Log when serving stale data during revalidation
onDiscarded: () => {
metrics.increment('swr.stale_served', { key });
}
});
// Track if we're showing stale data
if (result.isValidating && result.data) {
metrics.gauge('swr.stale_age', Date.now() - startTime, { key });
}
return result;
}
Combine SWR with cache warming for critical content. If you know certain content will be high-traffic immediately after publication—product launches, breaking news, major updates—proactively push it to caches before users request it. CloudFront supports cache invalidation with immediate replacement, allowing you to purge old content and populate new content atomically. This prevents the first wave of users from experiencing cache misses while ensuring everyone gets fresh content immediately.
Design your SWR configuration to gracefully handle origin failures. Set stale-while-revalidate values long enough to cover typical incident response times. If your team's mean time to resolution for origin issues is 15 minutes, consider stale windows of at least 30-60 minutes. This allows your application to remain fully functional during brief outages. Combine this with stale-if-error directives where supported, explicitly allowing stale content when origins return 5xx errors. This transforms cache from a performance optimization into an availability tool.
// Resilient caching headers for high-availability
res.set({
'Cache-Control': 'public, max-age=300, stale-while-revalidate=3600, stale-if-error=86400',
'Surrogate-Control': 'max-age=300, stale-while-revalidate=7200',
'CDN-Cache-Control': 'max-age=600'
});
// This configuration:
// - Browsers keep content fresh for 5min, serve stale for 1hr during revalidation
// - On origin errors, browsers can serve stale for up to 24hrs
// - CDN edge keeps fresh for 5min, serves stale for 2hrs during revalidation
// - CDN explicitly configured with 10min max-age via CDN-Cache-Control
Document your caching strategy comprehensively. SWR introduces complexity that future engineers (including yourself) will need to understand. Document which content types use SWR, what TTL values you chose and why, how to purge caches when necessary, and what monitoring dashboards track cache health. Include runbooks for common scenarios: how to investigate stale content reports, how to force refresh after emergency updates, and how to diagnose revalidation failures. This documentation becomes crucial during incidents when teams need to quickly understand caching behavior.
Test your SWR implementation under realistic failure scenarios. Simulate origin outages and verify that stale content serves correctly. Test revalidation behavior under high concurrency to ensure request deduplication works. Verify that your monitoring alerts fire appropriately when revalidation fails. Load testing should include scenarios that exercise the stale window, not just steady-state fresh cache hits. These failure mode tests build confidence that SWR improves availability rather than introducing subtle failure cases.
Conclusion
Stale-while-revalidate represents a fundamental shift in how we think about caching—from binary fresh/expired states to a nuanced approach that prioritizes user experience and system resilience. By serving cached content immediately while asynchronously fetching updates, SWR delivers consistent fast performance without sacrificing data freshness. This pattern has proven its value across the full stack, from HTTP-level CDN caching to client-side data fetching libraries, because it addresses a universal challenge in distributed systems: balancing consistency, availability, and performance.
The pattern's widespread adoption reflects broader industry trends toward optimistic UI patterns, eventual consistency, and graceful degradation. Modern applications increasingly accept brief staleness in exchange for better user experience and higher availability. SWR formalizes this trade-off with clear semantics and proven implementations. Whether you're configuring CloudFront distributions, implementing React data fetching, or designing API caching strategies, understanding stale-while-revalidate gives you a powerful tool for managing the performance-freshness spectrum. Applied thoughtfully with proper monitoring and tuned TTL values, SWR can dramatically improve both user experience and system reliability.
Key Takeaways
- Tune TTL values based on data characteristics: Analyze your content's update frequency and staleness tolerance. High-volatility data needs shorter fresh windows and shorter stale windows. Relatively static content can use aggressive caching with long stale periods. There's no universal configuration—align your cache settings with your data's actual behavior.
- Implement comprehensive observability: Track not just cache hit rates but revalidation frequency, background request failures, and actual staleness experienced by users. Use CloudFront cache status codes, instrument client-side SWR libraries, and correlate cache behavior with user experience metrics. Visibility enables optimization and rapid incident response.
- Design for cascading cache failures: When implementing multi-tier caching (CDN + browser + client-side state), align TTL values to prevent worst-case compounding staleness. Consider maximum acceptable staleness and work backwards to set appropriate values at each tier. Plan for explicit cache invalidation when you need strong consistency.
- Use SWR as an availability tool: Configure
stale-while-revalidatewindows long enough to cover typical incident response times. This transforms your cache from a performance optimization into a failure mitigation strategy that keeps applications functional during origin outages. Combine withstale-if-errorfor maximum resilience. - Test failure scenarios explicitly: Don't just test happy-path cache hits. Simulate origin failures, high concurrency during revalidation, and cache invalidation race conditions. Verify that your monitoring alerts fire correctly and that stale content serves as expected. Load tests should exercise the stale window, not just fresh cache states.
References
- Nottingham, M. (2010). RFC 5861 - HTTP Cache-Control Extensions for Stale Content. Internet Engineering Task Force (IETF). https://tools.ietf.org/html/rfc5861
- Fielding, R., et al. (2022). RFC 9111 - HTTP Caching. Internet Engineering Task Force (IETF). https://www.rfc-editor.org/rfc/rfc9111.html
- Amazon Web Services. (2024). Amazon CloudFront Developer Guide - Optimizing Caching and Availability. https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/
- Vercel. (2024). SWR - React Hooks for Data Fetching. https://swr.vercel.app/
- Grigorik, I. (2013). High Performance Browser Networking. O'Reilly Media.
- Nottingham, M. (2024). Caching Tutorial for Web Authors and Webmasters. https://www.mnot.net/cache_docs/
- Amazon Web Services. (2024). CloudFront Origin Shield Documentation. https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/origin-shield.html
- TanStack. (2024). TanStack Query (React Query) Documentation. https://tanstack.com/query/
- Kleppmann, M. (2017). Designing Data-Intensive Applications. O'Reilly Media. (Chapter on Caching and Consistency)
- Mozilla Developer Network. (2024). HTTP Caching - HTTP | MDN. https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching