Overall architecture class

1. Overall process of HTTP caching

1. 浏览器加载资源 → 检查 Service Worker
    ├─ 若 SW 拦截 → 使用 SW 策略返回资源
    └─ 否则进入浏览器缓存流程

2. 检查 Memory Cache
    ├─ 若存在且有效 → 直接返回（最快），停止流程
    └─ 否则检查 Disk Cache

3. 检查强缓存（Cache-Control/Expires）
    ├─ 若命中 → 直接返回本地缓存
    └─ 未命中 → 进入协商缓存

4. 检查 ETag / Last-Modified
    ├─ 有缓存标记 → 发条件请求
        ├─ 304 → 使用本地缓存
        └─ 200 → 使用新资源并更新缓存
    └─ 无缓存标记 → 直接下载新资源

5. 根据响应头决定是否写入缓存
    ├─ 写入 Memory Cache / Disk Cache
    └─ 或不缓存（no-store）

In HTTP cache control, when it comes to the browser sending 条件请求（Conditional Requests） To verify whether the resource has expired, ETag and Last-Modified The order of priority is clear.

---

🥇 Priority summary

ETag has higher priority than Last-Modified.

This means that if the HTTP response header contains both ETag and Last-Modified, the browser will give priority to using the ETag-based mechanism when making subsequent conditional requests.

Detailed explanation

1. When the server responds (Set Cache) When the server returns resource content, it usually sets these two headers:

   HTTP/1.1 200 OK
   Last-Modified: Tue, 25 Nov 2025 08:00:00 GMT 
   ETag: "v1.2.3-1a2b3c4d5e" 
   Content-Length: 1024

2. When the browser requests again (Conditional Request) When the browser needs to request the resource again, it will put these two values into the corresponding conditional request headers:

   • If-None-Match (corresponds to ETag)
   • If-Modified-Since (corresponds to Last-Modified)

   The request header sent by the browser will contain:

   GET /style.css HTTP/1.1
   If-None-Match: "v1.2.3-1a2b3c4d5e" 
   If-Modified-Since: Tue, 25 Nov 2025 08:00:00 GMT

3. Server processing (Priority Check) After the server receives the request, it will first check If-None-Match (that is, ETag).

   • If If-None-Match is present, the server ignores If-Modified-Since and only authenticates against the ETag.
     • Matches: Returns 304 Not Modified.
     • No match: Returns 200 OK and new content.
   • If If-None-Match does not exist, the server will check If-Modified-Since (ie Last-Modified).

Why does ETag have higher priority?

ETag is an opaque server-generated validator using, for example, a content hash, modification time or revision. The protocol specifies no algorithm and permits weak tags.

Property	Last-Modified	ETag
Granularity	Usually second precision	Depends on generation, with strong tags distinguishing representation data
Clocks	Echoes a server timestamp; client clock synchronization is not required	The client echoes rather than calculates the tag
Content changes	Timestamp changes can cause downloads	Content hashes recognize identical content; other strategies may not
Regeneration	The timestamp may change	Tag stability depends on generation strategy

When If-None-Match and If-Modified-Since coexist, the former takes precedence. Strong/weak validation describes semantics, not a blanket ETag-strong/Last-Modified-weak distinction.ETag documentation.

---

Here’s a summary Popular but professional , suitable for interview answers Summary of HTTP caching mechanism (Interview version + work practice version).

2. Strong Cache

👉 Features

• Does not communicate with the server, reads directly from the local cache
• best performance

👉 Key response headers

(1) Expires

• HTTP/1.0

• An absolute time, for example:

  Expires: Wed, 21 Oct 2025 07:28:00 GMT

• Disadvantages: Affected by client time (if the user modifies the system time, it may become invalid)

(2) Cache-Control

• HTTP/1.1
• More recommended
• Common values:

Command	Description
max-age=3600	cache 3600 seconds
public	All objects (including CDN) are cacheable
private	Only browser cacheable
no-cache	Not not caching, but must negotiate verification
no-store	No caching at all

Example:

Cache-Control: public, max-age=3600

3. Negotiated Cache

👉 Features

• The browser needs to confirm with the server whether the cache can continue to be used
• If the resource has not changed: return 304 Not Modified and continue to use local cache
• Changed: Return 200 OK + new resources

👉 Key request/response headers

(1) Last-Modified / If-Modified-Since

• The server returns the last modification time of the resource:

  Last-Modified: Wed, 21 Oct 2025 07:28:00 GMT

• The browser will bring:

  If-Modified-Since: Wed, 21 Oct 2025 07:28:00 GMT

• Disadvantages:

  • The accuracy is only seconds
  • Files are frequently changed but the content remains unchanged → will lead to unnecessary updates

(2) ETag / If-None-Match

• ETag is an opaque server-generated validator, not necessarily a content hash.
• Tag stability for identical content depends on generation; a content-hash scheme provides that property.

Example:

ETag: "abc123"

The browser next requests:

If-None-Match: "abc123"

⚠️ Note: ETag has higher priority than Last-Modified

4. Summary of strong caching vs negotiated caching

Cache type	Whether to access the server	Status code	Advantages	Disadvantages
Strong caching	❌ No access to the server	200 (from disk/memory)	Best performance	Expiration policy needs to be set
Negotiate cache	✔️ Will access the server	304	Avoid misuse of old cache when content changes	There is still network overhead

5. Examples of different cache hits (browser Network panel)

Cache Type	Network Display
memory cache	from memory cache
disk cache	from disk cache
Strong cache hit	200 OK (from cache)
Negotiated Cache Hit	304 Not Modified

6. Common front-end caching strategies (frequently asked questions in interviews)

🎯 1. Static resources (JS/CSS/images)

Scheme: long cache + file name hash

Cache-Control: max-age=31536000, immutable

• Add hash when building, such as: app.8a2c3.js
• File update → hash change → browser re-download

🎯 2. HTML resources

Do not cache for long periods of time

Cache-Control: no-cache

Because the HTML needs to reflect updates immediately

🎯 3. Interface data

Available on request:

• GET cacheable: Cache-Control: max-age=30
• POST is generally not cached

7. Browser cache location (bonus points)

Cache location	Features
Memory Cache	High priority, cleared after the page is closed
Disk Cache	Durable, large capacity
Service Worker Cache	Free control of caching logic (PWA)
IndexDB/LocalStorage	Manual storage, not HTTP cache

8. Interview answer template

HTTP caching is divided into strong caching and negotiation caching. Strong cache is implemented through Expires and Cache-Control. If the strong cache is hit, the browser will not communicate with the server; Negotiation caching is implemented through Last-Modified/If-Modified-Since and ETag/If-None-Match. If the resource has not changed, the server returns 304. Generally, we use long cache for static resources and control updates through file hash; we use no-cache for HTML to ensure timely updates.

Q1 - Design a globally distributed caching system to accelerate static resources and APIs. Please draw the high-level architecture and explain the responsibilities of each layer.

Answer Key

• Level: Browser cache (memory/disk) → Edge CDN (POPs) → Edge Workers / Edge Cache → Regional cache / Reverse proxy (Nginx/HAProxy + proxy_cache) → Origin / App servers → DB/Storage.

• Responsibilities:

  • Browser: Short-term fast hits, reducing round-trips.
  • CDN POP: geographically close service, reducing TTFB, caching static and some APIs.
  • Edge Workers: Implement authentication, A/B, image processing, and stale strategies.
  • Regional cache: ease the pressure on origin, do longer cache and complex revalidation.
  • Origin: eventually consistent data, permission verification, dynamic rendering. Project Note

• Each layer requires logs/indicators, unified cache-key rules, circuit breaker and back-to-source current limiting, hot standby and multi-active.

Designing a globally distributed caching system to accelerate static resources and APIs requires a multi-layered architecture with clear division of labor.This architecture typically combines a CDN, edge caching, and origin caching to achieve low latency and high availability.

🗺️ High-level architecture of global distributed cache system

graph TD
    subgraph Client Layer
        A[🌎 Global Users/Clients]
        B[🤝 DNS/Routing]
    end

    subgraph Edge Layer (Closest to Users)
        C1[🌐 CDN Edge Node 1 (Local POP)]
        C2[🌐 CDN Edge Node 2 (Remote POP)]
    end

    subgraph Regional/Mid-Tier Layer (Closer to Origin)
        D1[📍 Regional Cache/Mid-Tier Proxy]
        D2[📍 Regional Cache/Mid-Tier Proxy]
    end

    subgraph Origin Layer (Source of Truth)
        E[☁️ API Gateway / Load Balancer]
        F[💻 Web/API Servers (Compute)]
        G[💾 Static Asset Storage (S3/GCS)]
        H[🔥 In-Memory Cache (Redis/Memcached)]
        I[🗄️ Database (DB)]
    end

    A -->|Request (API/Static)| B
    B -->|Route to Nearest POP| C1
    B -->|Route to Nearest POP| C2

    C1 -->|Cache Miss/Validation| D1
    C2 -->|Cache Miss/Validation| D2

    D1 -->|Cache Miss/Validation| E
    D2 -->|Cache Miss/Validation| E

    E -->|Route API Request| F
    E -->|Route Static Asset Request| G

    F -->|Data Access| H
    F -->|Data Access| I

    C1 <-.-> |Cache Refresh/Pre-fetch| G
    C2 <-.-> |Cache Refresh/Pre-fetch| G

    style A fill:#f9f,stroke:#333
    style C1 fill:#ccf,stroke:#333
    style C2 fill:#ccf,stroke:#333
    style D1 fill:#ddf,stroke:#333
    style D2 fill:#ddf,stroke:#333
    style E fill:#faa,stroke:#333
    style G fill:#afa,stroke:#333
    style H fill:#fcc,stroke:#333

---

📜 Description of responsibilities at each level

1. Client Layer

Components	Responsibilities	Resource Types
Global Users/Clients	The end user, browser, or mobile application that initiated the request.	N/A
DNS/Routing	Global traffic scheduling portal. Route user requests to the geographically closest CDN edge node (POP) via a DNS service such as GeoDNS or Anycast IP.	N/A

2. Edge Layer (CDN)

This is the first line of defense of the acceleration system, closest to the user and used to handle most requests.

Components	Responsibilities	Resource Types
CDN Edge Node (POP)	Terminate user connection and respond quickly.
Static Resources	Cache Cache-Control: public resources (JS, CSS, images, videos, etc.).The target hit rate is as high as 95%+.	Static resources
API/Dynamic Resources	Cache short-lived dynamic content or public API responses.Determine whether to cache based on request headers (such as Authorization) or cookies.	API
Main functions	TLS/SSL offloading, request rate limiting, DDoS protection, WAF (Web Application Firewall), etc.	N/A

3. Regional/Mid-Tier Layer

Typically consists of a CDN or independent reverse proxy cluster, serving as the aggregation layer between edge nodes and origin servers.

Components	Responsibilities	Resource Types
Regional Cache/Proxy	Share the pressure of the origin site and improve the efficiency of return to the origin. Cache requests that do not hit the edge node.Because the number of nodes is smaller and more concentrated, the cache capacity is larger, the cache hit rate is higher than that of the edge layer, and the return-to-origin distance is shorter.	Static Resources & API
Main functions	Centralized cache purging (Purge) mechanism, cache pre-warming (Pre-warming).	N/A

4. Origin Layer - Source of Truth

The backend infrastructure that delivers final content is the authoritative source of data and logic.

Components	Responsibilities	Resource Types
API Gateway/Load Balancer	Unified entrance, responsible for request authentication, current limiting, distributing API requests to application servers, and directing static resource requests to storage services.	API & Static Resources
Web/API Servers	Process dynamic business logic. Responsible for calculations, user authentication, session management and generating dynamic responses.	API
In-Memory Cache (Redis)	Apply local cache. Store frequently accessed business data, user sessions, calculation results, etc. for quick query by the API server to reduce database pressure.	API data
Static Asset Storage (S3/GCS)	The final location where all static assets are stored. Provide high availability and high durability object storage services.	Static resources
Database (DB)	Stores persistent, structured business data.	Business Data

---

✅ Key design considerations

1. Cache Keys: Ensure that clear cache keys are defined for API requests to isolate requests from different users and different parameters.
2. Cache Invalidation (Invalidation/Purge): A fast cache invalidation mechanism must be provided.For key resources, use Tag-based or Instant URL refresh to ensure data consistency.
3. Cache Penetration/Avalanche/Breakdown:
   • Penetration: The edge layer and the middle layer return a null value with a short expiration time or use a Bloom filter for non-existent Keys.
   • Avalanche: To avoid a large number of caches expiring at the same time, use randomized expiration times.
   • Breakdown: Use origin site locks (such as Redis distributed locks) to ensure that there is only one request back to the origin to load data.
4. Dynamic content acceleration: For APIs that cannot be cached, you can use the Route Optimization and TCP Optimization functions provided by CDN vendors to accelerate the connection from the edge to the origin site.

Q2 — How to design the cache key to simultaneously support variants (device, language, resolution, format) and ensure a high hit rate?

Answer Key

• Basic formula: <method>:<normalized-path>?<normalized-query>|<vary-signature>
• Two principles: minimum necessary differentiation (add Vary only in necessary dimensions) and normalization (remove meaningless queries, sorting, and lowercase).
• Vary dimensions: Accept-Encoding for encodings such as gzip/br and Accept for formats such as webp/avif. Images can use explicit variant URLs; key Client Hints on headers affecting content or a normalized variant. Project Note
• Replace complex queries with cache tags or version numbers; use CDN’s custom cache key function; use deterministic transformation ids (hash of transformation parameters) for images/videos.

2. Invalidation/update/deletion strategy

Q3 — Please compare and design three cache update strategies: Time-based TTL, Push Invalidation (active clearing), Versioning (file name/URL version).

Answer Key

• TTL: simple, suitable for stable resources; disadvantages: update delay (not visible before expiration or revalidate required).
• Push Invalidation: real-time, suitable for strong consistency scenarios; complex implementation (requires reliable asynchronous notification), may cause large-scale instantaneous failures.
• Versioning (hash URL): The most recommended static resource: the new URL when released, the old URL is permanently valid; advantages: no complicated invalid logic, CDN + browser can cache for a long time. Project Note
• Consider push invalidation for configuration/privileged data; give priority to versioning for static resources; a mixed strategy is most realistic (HTML no-cache + versioned assets).

Q4 — How to avoid cache inconsistency (different nodes returning different versions) in a distributed environment?

Answer Key

• Principle: Avoid machines generating "unstable" identifiers (Last-Modified based on file timestamp).Unify the ETag/version generated by the build system or CDN.
• Solution: embed artifact id / git hash in the build product; use CDN centralized metadata (origin id); use content hash for ETag. Project Note
• For third-party or dynamically generated resources, use centralized metadata services or consistent hashing for key generation.

3. Cache failure/problems under high concurrency

Q5 — Explain cache breakdown/cache penetration/cache avalanche and design mitigations.

Answer Key

• Breakdown (cache miss on hot key): A large number of requests for a hot key fall to the backend at the moment the TTL expires. Mitigation: mutex (mutex) or request merge (singleflight), early rebuild (pre-warm), random TTL (jitter) or stale-while-revalidate.
• Penetration (non-existent keys): Malicious or erroneous requests bypass the cache and go directly to the DB (such as the key does not exist). Mitigation: Use Bloom filter/negative cache (short TTL)/verify input validity.
• Avalanche (large area simultaneous failure): A large number of caches expire at the same time, causing the backend to crash. Mitigation: TTL plus jitter (randomization) / batch failure / circuit breaker and degradation / hot key retention policy. Project Note
• In distributed systems, prefer singleflight service layer, combined with indicator alarm (QPS burst detection) and circuit-breaker.

Q6 - Detailed design of a "request merging (singleflight)" module to prevent cache penetration, describing boundary conditions and implementation details.

Answer Key

• Component: in-flight map (key -> promise/future + waiting list + timeout), the first request triggers return to the source and stores the promise in the map; subsequent requests are suspended waiting for promise resolution; timeout triggers rollback (returning old value or error).
• Boundary: concurrency limit, memory leak prevention (cleaning timeout entry), failure retry/degradation, priority or queuing strategy. Project Note
• Set reasonable timeouts and downgrade strategies for long-running requests; use stale-while-revalidate in conjunction with the cache layer to return old values to improve availability.

4. CDN and Edge/Worker Design

Q7 — How to implement the “stale-while-revalidate” and “stale-if-error” strategies at the CDN edge to ensure consistency and control of resource return pressure?

Answer Key

• Let the CDN: immediately return the old cache (stale) after the TTL expires, and asynchronously request the origin to update the cache (revalidate).If revalidate fails, stale will continue to be returned based on stale-if-error.Limit the concurrent amount of revalidate at the same time (single key limit) and set the return-to-origin rate limit. Project Note
• Use CDN's built-in function or write edge worker (Edge Function) to implement request merging; monitor the return-to-origin QPS and error rate.

Q8 — How to design edge computing (Edge Workers) to do A/B testing without polluting the cache (avoiding cache pollution).

Answer Key

• Principle: Don't mix experimental variables in cache keys that will lead to generalization.Method:

  • Place A/B testing decisions at the edge worker layer and put experiment results into response headers (without affecting the cache key), while using different cache keys (such as path|variant) for the same variant, or setting Cache-Control: no-store for the experiment request.
  • Or use cookie/authorization for offloading and explicitly include the variant id in the cache key (if variants need to be cached). Project Note

• Monitor cache hit rate and cache fragmentation; limit the number and life cycle of experiments.

5. Pictures/Media (especially the srcset you mentioned)

Q9 — How to design cache to achieve high hit rate and low storage cost when a large number of images use srcset, different resolutions and formats (webp/avif)?

Answer Key

• Problem: Having multiple variations (size, quality, format, DPR) of the same image can greatly increase the number of cache entries (fragmentation).

• Solution:

  1. Standardized variant naming/transformation id: Maps transformation parameters (width, quality, format, dpr) to a short transform-id (hash), image URL contains transform-id (e.g. /images/abc123__t=WxQf.avif or /images/abc123_t_<hash>.avif).In this way, the CDN cache key is simple and controllable.
  2. Use Client Hints (Accept-CH) and Edge Resizing: The client sends DPR / Width hints, and the Edge Worker generates or selects appropriate variants based on the hints and returns cached variants (to avoid UA sniffing causing Vary: User-Agent).
  3. Incorporate small variants/support adaptive quality: return higher quality to high-resolution devices at the edge and medium quality to mid-range devices; use dynamic cropping but speed-limited return to origin for extreme requests.
  4. Normalize cache key: Let CDN ignore non-essential queries (utm, etc.) and only cache based on transform-id and path.
  5. Cache level: POP caches commonly used small-sized, popular variants; Regional cache retains a few high-cost variants; Origin stores original images (master). Project Note

• Use immutable versioning combined with purge-by-tag (CDN support) for batch invalidation; perform on-demand generation (on-demand) of many variants and cooperate with caching TTL.

• Monitor: variant hit rate, edge generation QPS, storage cost, bandwidth cost.

Q10 — Specific points to note about srcset and cache design (practical checklist)

Points List

• Try to use URL-based versioning (including transform id) and avoid relying on Vary: User-Agent.
• Support Client Hints (DPR, Width) and let Edge be responsible for variant selection, reducing Vary in the UA dimension.
• Pre-warm popular variants for common resolutions in srcset.
• Use Cache-Control: public, max-age=... + immutable for hashed variations of file names.
• Use shorter TTL or on-demand generation for unusual resolutions to avoid wasting POP capacity.
• Set Vary: Accept-Encoding (gzip, br) but try to avoid Vary: User-Agent.
• For CDNs, use a custom cache key: <origin-path>#<transform-id>#<encoding>.
• If using a third-party image CDN (such as imgproxy/Thumbor/CloudImage, etc.), make sure the transform parameter canonicalization (canonicalization) to improve hit rate.

6. Security/Authentication/Private Content Caching

Q11 — How to cache user private content (authentication required) while ensuring security?

Answer Key

• Strategy:

  • Signed URLs: Short-lived signed URLs (the CDN can cache this object), but per-user URLs do not share cache — good for private large objects (videos).
  • Edge Authorization + Cache Key Partition: Auth judgment is performed at the edge. If the resource can be shared by multiple users (based on role), only the role id is included in the cache key; if it is unique to each user, avoid caching or use per-user cache (which will lead to a low hit rate).
  • Cache-Control: private: Prevent shared cache at the browser level, and the CDN layer requires special configuration. Project Note

• Avoid caching responses with Authorization headers at the public CDN stage, or split auth at edge, resource caching after proving access on the CDN side.

Q12 — How to securely cache responses containing Set-Cookie or Authorization headers?

Answer Key

• The default is not to cache responses with Set-Cookie at the CDN layer (because the cookie indicates that the response is session-related).General approach:

  • Separate static resources from session-related content at origin (put Set-Cookie only in HTML/API).
  • For APIs that need to be cached, use token-in-cookie but do token validation on edge, and explicitly specify that the cache key does not include cookies (or includes anonymous/role). Project Note

• Clarify legal/privacy boundaries (e.g. GDPR), log and provide automatic expiration and auditing of cached data.

7. Monitoring/Indicators/Observability

Q13 — Design a cached observability system (what indicators, alerts, and dashboards are needed)?

Answer Key

• Indicators:

  • Cache Hit Ratio (overall/by path/by POP)
  • Origin QPS，Cache Ejection Rate
  • 95/99 p95/p99 latency (edge vs origin)
  • Bandwidth saved（GB）
  • Error rates on revalidate/backfill
  • Cache key cardinality (fragmentation indicator)

• Alarm:

  • Sudden drop in hit ratio, sudden increase in origin QPS, increase in return-to-origin error rate, storage peak alarm

• Dashboard:

  • By region/pop/top paths/detail per transform-id Project Note

• Log sampling needs to be cost-effective; use tracing to trace the cold start to the hit path.

8. Cost/Storage/Cleanup Strategy

Q14 — How to choose the elimination strategy (LRU / LFU / but according to object weight) under the limited cache capacity of the POP layer?

Answer Key

• Limitations of traditional LRU/LFU: Object size and bandwidth savings are not considered.Should use cost-aware eviction: sort by object "cost per byte" or "value = hit_count * size_saved - storage_cost".
• Hierarchical cache can also be used: hot cache (small & hot items) + cold cache (large objects). Project Note
• Real-time computation is expensive and uses approximate algorithms (TinyLFU, Segmented LRU) combined with size-bucket partitioning.

9. Operation/Grayscale/Rollback

Q15 — How to do grayscale/rollback when releasing a new cache policy (such as changing HTML to no-cache or images to long-max-age)?

Answer Key

• Phased rollout: small amount of POP/region/traffic % → observe key metrics (hit-rate, origin QPS, errors) → expand rollout.
• Fast rollback: route requests back to the old policy via CDN rule or feature-flag; prepare purge and emergency throttle in advance. Project Note
• Do a good job in AB test isolation to avoid cache fragmentation.

10. High-frequency interviews/chasing questions (inspection depth)

Q16 - If origin wants to force a resource to be updated in the next 5 minutes but the resource has a 1 year TTL, how to do this?

Answer Key

• Method: Push purge (CDN API purge by URL / tag) or do a revalidation trigger (send invalidation event) in the cache layer supported by CDN; or add version param to the origin URL and then update the asset URL (best), or use short-lived cache + aggressive versioning. Project Note
• Purge cost and delay, design should consider purge rate limit and abuse protection.

Q17 — Discuss the impact of Vary headers on caching and the risk of abuse.

Answer Key

• Vary specifies which request headers affect response content (e.g. Accept-Encoding, User-Agent, Accept).
• Risk: Vary: User-Agent is easily prone to cache fragmentation (each UA is an independent entry), seriously reducing the hit rate.
• Recommendation: Try to use Client Hints (DPR/Width) + Edge transform to avoid relying on User-Agent; fine-grained Vary is only used for really necessary content negotiation. Project Note
• Check if the CDN honors Vary. In some CDNs Vary will be ignored or cause unexpected behavior.

Q18 — Design a highly available purge/invalidation system (need to consider idempotence, rate limiting, failure retries).

Answer Key

• Components: invalidation API (receiving purge by URL/tag/pattern), queue system (Kafka/SQS), worker pool (partition concurrency, rate limit), and finally calling the CDN provider API and monitoring callbacks.
• Features: idempotent requests, batch processing, priority (emergency vs normal), fallback (use version bump if purge fails). Project Note
• Rate limit high-frequency automated purge to avoid cache churn caused by jitter.