Async http requests with ETag caching
Master System Design with Codemia
Enhance your system design skills with over 120 practice problems, detailed solutions, and hands-on exercises.
Introduction
Asynchronous HTTP requests and ETag caching solve two common performance problems at once: blocking network calls and redundant payload downloads. Async execution keeps the application responsive, and ETag revalidation avoids transferring unchanged resources. Used together, they reduce latency, bandwidth, and backend load without complex infrastructure.
Core Sections
How ETag Revalidation Works
An ETag is a version token generated by the server for a specific representation of a resource. The client stores that token and sends it back in If-None-Match on later requests.
If the resource did not change, the server responds with 304 Not Modified and no body. If changed, the server returns 200 with fresh content and a new ETag. This pattern is ideal for configuration documents, profile data, and reference lists.
Async Client Request with Conditional Headers
A practical client keeps both payload and ETag in a local cache. On refresh, it revalidates instead of downloading blindly.
This keeps reads asynchronous and avoids stale network payloads when content is unchanged.
Server-Side ETag Generation in Node
Server implementation can use a content hash, version column, or updated timestamp to produce ETag values.
Strong consistency is easier when ETag generation is deterministic for the exact response body.
Race Control for Repeated Async Requests
UI code often triggers repeated fetches from typing, tab switches, or polling. If requests overlap, stale responses can overwrite newer data. Track request tokens or use abort signals to keep order deterministic.
Use one in-flight request per resource key in most UI cases. This avoids duplicate revalidation traffic and stale updates.
Cache Policy and Expiration Strategy
ETag revalidation is best for mutable data where freshness matters. Combine it with Cache-Control depending on requirements. Short max-age plus revalidation often balances speed and correctness.
For APIs that change rarely, longer max-age reduces round trips. For volatile resources, keep max-age small and rely on lightweight 304 responses.
Observability and Testing
Measure the ratio of 304 to 200 responses to confirm the cache strategy works. High 200 rates on stable resources often signal missing or unstable ETag generation.
Automated tests should assert both unchanged and changed resource paths.
Common Pitfalls
- Generating ETags from unstable values, which prevents
304hits. - Returning
304without previously caching the response body client-side. - Ignoring overlapping async requests and allowing stale UI overwrite.
- Using ETag caching for sensitive user-specific data without private cache controls.
- Forgetting to monitor
304rates, making cache regressions hard to detect.
Summary
- Async HTTP keeps clients responsive while requests are in flight.
- ETags enable low-cost revalidation through
If-None-Matchand304. - Deterministic ETag generation is essential for reliable cache behavior.
- Request cancellation and in-flight control prevent stale response races.
- Metrics and tests should validate that caching actually delivers benefit.

