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

28 practiced

List scenarios where caching can hurt correctness or performance and should be avoided or applied cautiously, such as real-time financial data, per-request personalization, strong consistency requirements, or high-churn keys. For each scenario explain why caching is problematic and suggest alternative approaches or mitigations.

Sample Answer

**Overview**Below are common scenarios where caching can hurt correctness or performance, why it’s problematic for a full‑stack app, and practical alternatives or mitigations.

**1) Real‑time financial or market data**- Why problematic: Even small staleness causes incorrect trades, balances, or regulatory issues.- Mitigation/Alternative: Avoid long‑TTL caches; use streaming (WebSocket) or push updates, server‑side in‑memory with very short TTLs, and read‑through caches with cache invalidation on updates. Use strong consistency on critical paths (direct DB or transactional APIs).

**2) Per‑request personalization (user-specific UI)**- Why problematic: Shared caches can serve another user’s content or stale personalization.- Mitigation: Cache only user‑agnostic fragments; use per‑user caches keyed by secure user id or session token and encrypt keys. Prefer client‑side localStorage/sessionStorage for non‑sensitive personalization and short lifetimes.

**3) Strong consistency requirements (inventory, seat booking)**- Why problematic: Race conditions and overselling if cached values are read/written without atomicity.- Mitigation: Implement optimistic locking, distributed locks, or canonical writes to the database; consider write‑through caches that update cache synchronously on commit, or avoid caching the authoritative counter.

**4) High‑churn keys (rapidly changing hot keys)**- Why problematic: Cache thrashing causes frequent evictions, high misses, and extra load on origin.- Mitigation: Reduce cache usage for these keys, use rate‑limiting, request coalescing (lock per key), or short TTL + jitter. Consider materialized views or batching updates.

**5) Sensitive or regulated data**- Why problematic: Storing PII or regulated data in shared caches risks leakage and compliance violations.- Mitigation: Don't cache sensitive fields; if required, encrypt cached values and apply strict access controls and TTLs.

**6) Complex derived data requiring freshness**- Why problematic: Stale aggregates (dashboards, analytics) mislead users.- Mitigation: Use incremental recomputation, event sourcing, or cache invalidation on upstream events; mark UI as eventually consistent.

Keep caches focused on idempotent, read‑heavy, and non‑authoritative data. For each case weigh consistency vs latency and prefer application‑level safeguards (short TTLs, invalidation hooks, per‑user keys, locks) when you must cache.

HardTechnical

32 practiced

Analyze memory fragmentation and eviction tuning for Redis when storing many large objects of varying size. Discuss maxmemory-policy choices, memory-fragmentation-ratio, lazyfree-lazy-eviction, active defragmentation, impact of large-key eviction on latency, and recommendations to minimize OOMs and outage risk.

Sample Answer

**Situation & scope**Storing many large, variable-sized objects in Redis raises fragmentation, eviction complexity, and latency spikes. Below are analysis points and actionable recommendations a full‑stack developer should use when designing and tuning.

**Maxmemory-policy choice**- For mixed sizes prefer volatile-lru/volatile-ttl if keys have TTLs; otherwise allkeys-lru minimizes OOMs but may evict hot small keys. - Avoid noeviction for production of large objects; set policy to an LRU/approx-LRU variant to favor least-recent data.

**Memory fragmentation & memory-fragmentation-ratio**- Fragmentation grows when allocator (jemalloc) splits/allocates many different sized chunks. Monitor INFO memory -> memory_fragmentation_ratio.- Ratio > 1.5 indicates attention: investigate allocation patterns, large-object churn, or switch jemalloc tunables. Keep ratio ~1.1–1.3 for safety.

**Lazyfree-lazy-eviction**- Enable lazyfree-lazy-eviction to asynchronously free large keys so eviction doesn’t block the main thread. This reduces eviction latency but increases background GC/CPU.- Use when large-key deletes are frequent; ensure enough background threads (activedefrag/lazyfree workers).

**Active defragmentation**- Enable active-defrag to compact heap incrementally. It reduces fragmentation over time but consumes CPU—tune thresholds (defrag‑cycle/min‑keys). Useful when fragmentation ratio trends upward and CPU headroom exists.

**Impact of large-key eviction on latency**- Deleting or serializing very large keys can block I/O and increase p99 latency. Eviction of large items can cause pauses, key eviction storms worsen this.- Use object size caps, chunking (store large blobs in S3 and put pointers in Redis), or split objects across multiple keys to bound per‑key cost.

**Recommendations to minimize OOMs and outage risk**- Set realistic maxmemory with headroom for fragmentation (reserve ~20% extra).- Prefer approximate-LRU eviction plus lazyfree for large-key workloads.- Offload large binary objects to blob storage; keep Redis for metadata/indices.- Monitor fragmentation, eviction metrics, latency p99, and background job queue; add alerts.- Use Redis replication and persistence (AOF/RDB) tuned to avoid blocking saves; consider Redis Cluster to shard large-state.- Stress-test workloads simulating churn to validate settings before production.

These choices balance latency, CPU, and reliability for full‑stack systems handling large varying objects.

MediumTechnical

28 practiced

Design rules for edge cache key composition when requests include query strings and cookies. For example, search endpoints accept ?q= and pagination ?page=, while cookies include session info. Explain which query params should be part of the cache key, how to canonicalize and normalize query strings, how to deal with ordering and irrelevant tracking params, and how to ensure personalization doesn't leak between users.

Sample Answer

**Approach summary**Define a small deterministic set of inputs that affect response semantics, normalize them, and exclude anything that contains per-user secrets (session cookies). Use canonicalization + allowlist + consistent ordering so caches are sharable and safe.

**Which params to include**- Include: params that change content meaningfully (e.g., q, page, per_page, filters). - Exclude: analytics/tracking params (utm_*, fbclid), feature flags that don't change payload, and any param marked transient by product.- Prefer an explicit allowlist per endpoint (search: allow q,page,sort; listing: allow page,category).

**Canonicalization & normalization**- Percent-decode, trim whitespace, collapse repeated params per allowlist rule (take first or last), lowercase param names (but preserve case for values if significant).- Normalize values: trim, normalize unicode (NFC), collapse multiple spaces.- Sort params by name to ensure deterministic key.

Example normalization (JS):

javascript

function normalizeQuery(urlSearchParams, allowlist){
  const out = [];
  for(const key of Array.from(urlSearchParams.keys()).sort()){
    if(!allowlist.has(key)) continue;
    const val = urlSearchParams.getAll(key).join(','); // policy: join duplicates
    out.push(`${key.toLowerCase()}=${encodeURIComponent(val.trim())}`);
  }
  return out.join('&');
}

**Ordering & irrelevant params**- Remove irrelevant params first using a deny/allow pattern (deny known trackers, then allowlist remaining).- Sort remaining keys lexicographically.

**Cookies & personalization leakage**- Never include session_id or user-auth cookies in cache key.- For responses that vary by auth/user, either: - Don’t cache at the edge (or cache per-user in a private store), or - Cache a generic public version and use Edge Side Includes / personalizations at the edge using signed tokens or subrequests keyed by surrogate keys (e.g., X-Surrogate-Key) to fetch user fragments.- Use Vary header only for safe shared values (e.g., Accept-Language). Avoid Vary: Cookie unless you truly need per-cookie caching and isolate which cookie names are safe.- If partial personalization required, strip user-identifying cookies and add a non-sensitive "persona" header set by origin (e.g., X-User-Variant) that can be allowlisted into the cache key.

**Operational tips**- Log cache-key composition for a period to verify hit rates.- Keep allowlists small; update with rollout.- Provide a deterministic fallback for unknown params (ignore) and document behavior for front-end teams.

HardSystem Design

34 practiced

Design a write-behind queue system for caching writes to the persistent database. Include architecture for batching, backpressure, idempotence, retry semantics, failure handling, and guarantees (at-least-once vs exactly-once). Explain how you ensure durability of queued writes and how to drain the queue safely during maintenance or failure.

Sample Answer

**Overview / Requirements clarification**I would build a write-behind queue so application writes are acknowledged quickly while durable writes are serialized to the DB asynchronously. Key needs: batching, backpressure, idempotence, retries, durability, and safe drain.

**High-level architecture**- App servers push write operations into a durable queue (Kafka/RabbitMQ/Redis Stream) with metadata (id, timestamp, payload, version).- A worker pool reads the queue, groups messages into batches by shard/partition, and applies to DB via upserts/transactional batch APIs.- Offset/ack committed only after DB confirmation.

**Batching**- Batch by time (e.g., 50–200ms) or size (max 500 ops) and by key shard to avoid conflicting writes.- Coalesce sequential writes for same key (keep latest version) before dispatching.

**Backpressure**- Queue has capacity + partition-specific throttling.- App servers detect high queue lag (consumer lag metric) and slow down writes: return 429, buffer on client, or switch to synchronous writes for critical ops.- Circuit-breaker: if queue full beyond threshold, degrade non-critical features.

**Idempotence & Exactly-once / At-least-once**- Each operation carries a client-generated idempotency key and a monotonically increasing version.- Workers perform idempotent upsert semantics: write if version > stored version (compare-and-set) or use DB-side upsert with unique constraint on idempotency key.- Guarantees: system provides at-least-once delivery by default; with versioning/idempotent writes we approach effectively exactly-once side-effects.

**Retry semantics & failure handling**- On transient DB error: exponential backoff + retry up to N attempts; keep message in queue or move to a retry topic with delays.- On poison messages: route to dead-letter queue for manual inspection.- Worker crashes: consumer offset not committed → message reprocessed (safe because idempotent).- Monitor consumer lag, retry failures, DLQ rates with alerts.

**Durability**- Use a durable, replicated message store (Kafka with replication factor >=2) to persist queued writes.- Ensure producers wait for ack replication before acknowledging to clients when necessary.- Persist metadata (offsets, last-applied versions) in a reliable store.

**Draining safely**- Enter maintenance mode: stop accepting new writes or redirect to sync path; mark queue as draining.- Workers finish in-flight batches, then checkpoint offsets; pause consumers.- Use TTL/priority: critical writes can be forced synchronous; low-priority writes can be abandoned after policy.- Verify DB last-applied versions match queue offsets before fully shutting down.

**Operational considerations**- Metrics: queue depth, consumer lag, retry counts, DLQ rate, DB latency.- Testing: chaos tests for worker restarts, DB outages, duplicate delivery.- Trade-offs: stricter durability and idempotence adds latency/complexity; choose policies per feature criticality.

This design balances fast acknowledgements with durable, safe, and observable async persistence suitable for full-stack ownership.

MediumTechnical

36 practiced

You are building a comment system where new comments must be visible immediately to the author and followers and durability is important. Compare write-through and write-behind caching strategies for this use case and recommend one. Explain trade-offs around latency, durability, complexity, and how to guarantee immediate visibility to readers.

Sample Answer

**Direct answer / recommendation**I recommend a write-through strategy for the comment system. It gives better durability and simpler correctness for immediate visibility; write-behind risks data loss and stale reads unless you add extra complexity.

**Comparison (latency, durability, complexity)**- Write-through - Latency: higher write latency (sync write to DB + update cache) but predictable. - Durability: strong — DB durable before cache reflects state. - Complexity: low — single code path; easier to reason about consistency.- Write-behind - Latency: lower perceived write latency (ack after cache write), but actual persistence happens async. - Durability: weaker — crashes before flush can lose comments unless you add durable queue/WAL. - Complexity: high — requires reliable flushers, ordering guarantees, conflict resolution, monitoring.

**Guaranteeing immediate visibility to author & followers**- For author: return the saved comment in the HTTP response (or show optimistically) and write synchronously to DB. Also update/invalidate cache synchronously so reads see it.- For followers: push the new comment via WebSocket/Server-Sent Events or use a fanout job (async) — but don’t rely solely on async persistence for initial visibility. If fanout is async, ensure the write to DB completes first so followers receive durable content.- Additional patterns: - Read-your-writes: use session-local cache or include the newly created comment in API response so UI doesn’t wait for cache refresh. - Use Redis as cache + relational DB as source of truth; write-through means update DB then set cache atomically (or use a transaction + cache invalidation). - If using write-behind, require a durable queue (Kafka, Redis streams) and strict acking to avoid data loss — adds operational burden.

**Practical implementation notes (Full-Stack view)**- API flow: POST /comments → validate → INSERT comment (DB, with WAL fsync) → update/invalidate Redis → return comment and publish event to followers.- UI: optimistic rendering for instant UX; reconcile with server response to catch failures.- Monitoring: track queue length (if any), cache hit/miss, and lag between DB and cache.

Write-through favors correctness and simpler full-stack implementation where durability and immediate visibility are required.

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.