Caching and Performance Optimization Questions

Covers design and implementation of multi layer caching and end to end performance strategies for web and backend systems. Topics include client side techniques such as browser caching, service worker strategies, code splitting, and lazy loading for components images and data; edge and distribution techniques such as content delivery network design and caching of static assets; and server side and data layer caching using in memory stores such as Redis and Memcached, query result caching, and database caching patterns. Includes cache invalidation and coherence strategies such as time to live, least recently used eviction, cache aside, write through and write behind, and prevention of cache stampedes. Covers when to introduce caching and when not to, performance and consistency trade offs, connection pooling, monitoring and metrics, establishing performance budgets, and operational considerations such as cache warm up and invalidation during deploys. Also addresses higher level concerns including search engine optimization implications and server side rendering trade offs, and how performance decisions map to user experience and business metrics at senior levels.

EasyTechnical

29 practiced

Explain Time To Live (TTL) and Least Recently Used (LRU) eviction policies. For frontend or edge caches give one example where TTL is sufficient and one example where LRU is preferable.

HardTechnical

29 practiced

You want to A/B test a new caching strategy that changes TTLs and introduces edge stale-while-revalidate behavior. Design the experiment: what metrics to track (performance and business), how to split traffic safely, required sample size considerations for conversion metrics, and rollback criteria if customers are negatively impacted.

Sample Answer

**Situation & goal**I’d run an experiment to validate edge stale-while-revalidate + new TTLs improve perceived performance without harming conversions or error rates.

**Key metrics**- Performance (frontend-focused) - First Contentful Paint (FCP), Largest Contentful Paint (LCP) - Time to Interactive (TTI), Cumulative Layout Shift (CLS) - Cache hit ratio at edge, origin request rate, tail latency (p95/p99) - Stale responses served % and revalidate failures- Business - Conversion rate (primary CTA), bounce rate, session length, revenue per session - Error rate affecting UX (4xx/5xx, JS exceptions)

**Traffic split & safety**- Start with Canary: 1% control / 1% treatment for 24–48h, monitor errors and key perf metrics- If stable, ramp to 5%/5% → 20%/20% → 50%/50% over days; automatic stop on safety triggers- Use user-key hashing to keep users sticky to a variant and avoid mixing sessions

**Sample size for conversion**- Rough sample-size formula for detecting absolute delta d with baseline p and power/α:

text

n_per_group = 2 * p_bar * (1 - p_bar) * (Z_beta + Z_alpha/2)^2 / d^2

- Compute with baseline conversion, target minimum detectable effect (e.g., 5%), power 80%, α 0.05.

**Rollback criteria**- Immediate rollback if: - Error rate increase > 0.5% absolute or 2x baseline - Critical JS exceptions spike - Conversion drop > pre-defined MDE (e.g., 5%) with p < 0.05 - Severe perf regression (LCP p95 worsens > 250ms)- Graceful rollback plan: feature-flag switch, invalidate problematic caches, communicate with SRE/frontend.

**Monitoring & analysis**- Real-time dashboards, alerting, and segmented analysis by device/region/first-load vs navigations; run statistical tests and inspect qualitative feedback (session replay, support tickets).

MediumSystem Design

34 practiced

Design a practical CDN invalidation and deployment plan for frontend releases to avoid serving stale JS/CSS while minimizing costly full-cache purges. Explain how you would use versioned assets, surrogate keys, and a staged invalidation approach.

Sample Answer

**Clarify goals & constraints**- Prevent stale JS/CSS reaching users after a deploy- Avoid full-cache purge (costly / throttle-limited)- Keep cache-friendly long TTLs for static assets

**Core strategy (summary)**- Use content-hashed, versioned filenames for immutable assets (app.ab12cd.js)- Serve HTML (index.html) with short TTL and/or no-cache so it can reference new hashes quickly- Annotate CDN objects with surrogate-keys (logical tags) to allow targeted purges

**Asset versioning**- Build pipeline produces filenames using content hash (webpack/parcel/Vite): main.5f3a2.js, vendor.aa1b.css- Set Cache-Control: public, max-age=31536000, immutable for these files- index.html: Cache-Control: max-age=60, must-revalidate (or use stale-while-revalidate)

**Surrogate keys**- On upload to storage / CDN, set header: Surrogate-Key: app:v123 static:js- Keys composed of release id + asset type; e.g., release:20260301, js, css, images- Allows purging only keys for one release or asset type

**Staged invalidation approach**1. Deploy build artifacts to storage and CDN edge (upload hashed assets).2. Update backend or object serving index.html to reference new hashed filenames.3. Atomically swap index.html (or a redirect entry) so new index points to new hashes.4. Issue targeted CDN invalidation by surrogate-key for the new release (or for index.html only if using short TTL). Purge: Surrogate-Key: release:20260301 - This removes only edges that still reference old index / release keys.5. If a rollback is needed, publish previous index and purge new release key.

**Additional practices**- Canary rollout: serve new index to a small % of traffic (feature flags / A/B) before full purge.- Monitor error rates and asset 404s after swap; keep previous builds for quick rollback.- Automate purges in CI/CD with dry-run and rate-limit handling to avoid CDN quotas.

**Why this works**- Hashed filenames let browsers and CDN cache aggressively without staleness risk.- Short-ttl HTML ensures clients learn new hashes quickly.- Surrogate-key purges are precise and avoid full-cache costs.- Staged swap + canary reduces blast radius and supports fast rollback.

HardTechnical

29 practiced

You must design a robust cache invalidation procedure for frontend deploys that minimizes downtime and avoids serving stale pages across millions of CDN objects. Describe an operational plan that covers asset versioning, cache purges versus immutable assets, staged deployment, and rollback actions.

Sample Answer

**Situation & goal** Design a deploy-safe cache invalidation plan for frontend releases serving millions of CDN objects that minimizes downtime and eliminates stale pages.

**Asset versioning (immutable-by-default)** - Build outputs get content-hashed filenames (app.abc123.js, styles.def456.css). - HTML shell references exact hashes; static assets marked immutable with long max-age (Cache-Control: public, max-age=31536000, immutable). - Non-hashed resources (index.html, service-worker.js, manifest) use short TTLs (Cache-Control: public, max-age=60, must-revalidate).

**Cache purges vs immutable assets** - Prefer immutable hashed assets — no purge required. - Only purge when a critical bug exists in an already-deployed hashed asset; use targeted invalidation by exact URL/pattern. Avoid wildcard/global purges. - For index.html and API-proxy routes, use fast CDN API invalidation with rate limits and automated batching.

**Staged deployment & traffic shifting** - Canary deploy: push new build to 1% of edge/populations (via CDN config or header-based routing). Monitor errors, RUM, synthetic tests, and backend metrics for 15–30 minutes. - Gradually increase to 10%, 50%, then 100% when KPIs stable. Automate promotion with safety gates (error > X% rolls back).

**Rollback actions** - Immediate rollback: revert origin mapping to previous stable build (index.html referencing previous hashes) and/or route traffic away from new edge nodes. Because assets are immutable, client refresh will fetch stable index.html and then cached hashed files. - Emergency purge: if hashed asset must be removed, run targeted CDN purge + invalidate caches on service worker, and force clients to refetch (short-lived feature-flags to disable faulty code).

**Operational controls & automation** - CI/CD publishes manifests mapping logical names to hashed files; CI triggers CDN invalidations for non-immutable resources only. - Observability: RUM, CDN cache-hit ratio, error budget, and deploy playbooks in runbook. - Post-mortem: automatic rollback thresholds, and lessons feed into stricter preflight checks (linting, bundle diff, smoke tests).

This approach minimizes global purges, leverages immutable assets, stages risk with canaries, and gives clear, fast rollback paths.

MediumTechnical

29 practiced

Show an example webpack configuration snippet (or equivalent bundler) that implements asset fingerprinting for cache busting and explains how to configure the server or CDN to serve those immutable assets with long max-age headers while keeping HTML responses short-lived.

Sample Answer

**Approach (brief)** I fingerprint built assets using content hashing in filenames so any change produces a new URL. Then I configure the CDN/server to serve those hashed assets with long, immutable cache headers while keeping HTML short-lived so browsers re-request HTML and get new asset references.

**Example webpack snippet**

javascript

// webpack.config.js
const path = require('path');
const HtmlWebpackPlugin = require('html-webpack-plugin');

module.exports = {
  mode: 'production',
  entry: './src/index.js',
  output: {
    path: path.resolve(__dirname, 'dist'),
    // include contenthash for cache-busting
    filename: 'js/[name].[contenthash:8].js',
    chunkFilename: 'js/[name].[contenthash:8].chunk.js',
    publicPath: '/'
  },
  module: { /* loaders for JS/CSS/images */ },
  plugins: [
    new HtmlWebpackPlugin({
      template: './src/index.html',
      inject: 'body',
      minify: true
    })
    // optional: CleanWebpackPlugin to remove old files
  ],
  optimization: {
    splitChunks: { chunks: 'all' }
  }
};

**Why contenthash** - [contenthash] changes only when file content changes → stable URLs across builds when unchanged.- Works for JS/CSS/assets; for images/fonts use asset modules with filename '[name].[contenthash:8][ext]'.

**Server / CDN caching rules**- For fingerprinted static assets (js/css/img/fonts): - Response header: Cache-Control: public, max-age=31536000, immutable - This tells browsers/CDNs to cache for 1 year and not revalidate.- For HTML (index.html) and API responses: - Response header: Cache-Control: no-cache, must-revalidate, max-age=0 - Or: Cache-Control: private, max-age=0, must-revalidate - This forces the browser/CDN to check with origin for new HTML (and thus updated asset URLs).

**CDN configuration / invalidation**- Set two cache behaviors: path pattern for /assets/* or file extensions to long max-age; index.html (and routes) to short TTL.- Optionally enable "stale-while-revalidate" for slightly better UX.- Use cache invalidation only for emergencies; normal deployments rely on filename changes to serve new content.

**Practical notes**- Ensure HTMLWebpackPlugin injects hashed filenames so HTML always references correct assets.- Clean old assets on build or use lifecycle policy in storage (e.g., S3 lifecycle) to remove outdated files.- Test with browser devtools (Disable cache off) and CDN headers.

Unlock Full Question Bank

Get access to hundreds of Caching and Performance Optimization interview questions and detailed answers.

Join thousands of developers preparing for their dream job.