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

47 practiced

Explain the differences between cache-aside, write-through, and write-behind caching patterns. For each pattern describe how reads and writes flow, typical use-cases in backend systems, consistency and durability trade-offs, and one scenario where that pattern would be a poor fit.

Sample Answer

Cache-aside (lazy loading)- Read flow: App checks cache; on miss, reads DB, populates cache, returns value.- Write flow: App writes directly to DB then invalidates/evicts or updates cache.- Use-cases: Read-heavy workloads where cache is an optimization (CDN metadata, product catalog).- Consistency/durability: Stronger durability (writes go to DB first). Potential short window of stale reads if cache not updated atomically.- Poor fit: Highly write-heavy, low-latency consistency needs (e.g., financial ledger) — eviction/async update can cause stale reads.

Write-through- Read flow: App reads cache; on miss, cache loads from DB (or cache proxies it).- Write flow: App writes to cache; cache synchronously writes to DB before acknowledging.- Use-cases: Systems requiring simpler consistency between cache and DB (session stores, config flags).- Consistency/durability: Stronger read consistency than cache-aside because cache always reflects writes; durability depends on sync to DB — higher write latency.- Poor fit: Extremely write-heavy services where synchronous DB writes per update add unacceptable latency.

Write-behind (write-back)- Read flow: App reads cache; cache serves if present; on miss, load from DB.- Write flow: App writes to cache; cache acknowledges immediately and buffers/asynchronously flushes to DB.- Use-cases: High-throughput, write-heavy workloads where low write latency matters (analytics counters, transient metrics).- Consistency/durability: Lowest immediate durability and consistency — risk of data loss on cache failure and stale DB state until flush completes.- Poor fit: Any system with strict durability/ACID requirements (payments, inventory) because async flush risks lost updates.

Operational notes for SREs:- Monitor cache hit-rate, write-back queue size, flush latency, and tail latencies.- For write-behind, ensure persistent buffering (WAL) and safe eviction policies to reduce data-loss risk.- Choose pattern based on SLOs: consistency/durability vs latency and throughput trade-offs.

HardSystem Design

39 practiced

Design a hybrid caching architecture for personalized and non-personalized content that must remain GDPR-compliant (no PII stored at edge). Detail where to store encrypted/session tokens, how to cache user-agnostic fragments at the edge, and how to assemble pages without exposing PII. Include trade-offs.

Sample Answer

Requirements:- Serve mixed personalized + non-personalized pages with low latency via edge caches.- GDPR: no PII stored at edge; user-identifiers must be ephemeral/encrypted and user consent respected.- High availability and easy cache invalidation.

High-level architecture:Browser → CDN/Edge (Varnish/Cloud CDN + Edge Workers) → Origin API + Personalization Service → Secure Session Store / Token Service → Data Stores (user DB, content DB)

Key components & responsibilities:1. Edge CDN + Edge Workers: cache user-agnostic fragments (HTML fragments, assets, ILP - immutable layout pieces). Run tiny assembly logic (merge fragments + client-side placeholders). No PII persisted.2. Origin Renderer / Fragment Service: produces fragment versions (public fragments, personalized fragments signed with tokenized keys).3. Token Service / Session Store (central, not on edge): issues short-lived opaque session tokens (JWT-like but encrypted, minimal claims: token-id, cohort, expiry). Tokens stored server-side (Redis/managed KV) mapping token-id → user profile pointer; token payload contains only non-PII attributes or cohort ids. Token encryption keys rotate via KMS.4. Personalization Service (origin): on cache miss or authenticated personalize call, resolves token-id to user profile, computes per-user fragments server-side, returns signed ephemeral fragments to client.

Data flow / page assembly:- Public page served from edge with placeholders for personalized regions (divs with data-token and fragment-URL).- Client includes ephemeral token (httpOnly secure cookie or Authorization header) when requesting personalized fragment endpoints.- Edge forwards fragment request to Origin Worker which validates token signature or queries Token Service; Origin assembles personalized fragment server-side (ensures PII stays in origin), returns fragment; Edge can cache the fragment only if it’s non-PII and tagged by cohort and TTL. Otherwise set Cache-Control: private,no-store at edge and use short TTL plus Surge protection.- Optionally use Edge Workers to stitch cached public fragments and server-returned (non-PII) personalized fragments before responding.

Where to store encrypted/session tokens:- Tokens issued and encrypted with KMS-stored keys; token-id mapping stored in central session store (Redis/Encrypted DB). Cookies: httpOnly, Secure, SameSite=strict, minimal lifetime. Edge only sees opaque token string; no profile data.

How to cache user-agnostic fragments at edge:- Fragmentation strategy: split templates into immutable static fragments and dynamic regions.- Cache static fragments at CDN with long TTL + versioned keys.- Cache cohort-level dynamic fragments (A/B buckets, privacy-preserving segments) at edge keyed by cohort id, not user id.- Use surrogate-keys for invalidation.

Assemble pages without exposing PII:- Do server-side personalization at origin; return only rendering HTML snippets that contain no raw PII (use pseudonymous IDs or cohort tags).- Client-side rendering uses tokens to fetch personalized snippets over HTTPS. Logging redacts PII; edges never log token contents.- Audit trails and data access logs kept centrally, with retention controls for GDPR.

Trade-offs:- Latency: origin-side personalization adds round-trips; mitigate with edge workers, prefetch, and cohort caching.- Complexity: fragmenting templates and maintaining idempotent cache keys increases dev work.- Consistency: cohort caching may serve slightly stale personalization vs real-time origin responses.- Privacy vs performance: stricter privacy (no edge caching of any personalized content) simplifies compliance but increases load on origin and latency.- Key rotation & revocation: central token store eases revocation but adds dependency; fully stateless encrypted tokens reduce state but make revocation harder.

Operational considerations:- Monitor cache hit rates, origin request surge, token-service latency, error budgets.- Automated key rotation, consent flags enforcement, GDPR deletion workflow tied to session store and token invalidation.- Chaos tests for edge-origin failover, and rate-limits to protect origin from cache bypass spikes.

MediumTechnical

34 practiced

Propose a set of alerts and a short runbook for common cache-layer incidents: memory exhaustion, sustained high eviction rate, spike in misses, and replication lag. For each incident include the first three steps an on-call engineer should take and one automated mitigation.

Sample Answer

Memory exhaustion- Alerts: - cache_memory_used > 90% for 2m OR cache_free_bytes < X threshold - OOM events logged- First 3 steps: 1. Verify alert: check metrics (used, free, swap) and recent config changes. 2. Identify top keys / namespaces by memory (hot key scan, MEMORY USAGE / top-key script). 3. If safe, enable read-only or maintenance mode for non-critical traffic to reduce pressure.- Automated mitigation: Eviction policy shift: temporarily switch to a more aggressive eviction policy (e.g., allkeys-lru) and lower maxmemory via automated runbook to free space.

Sustained high eviction rate- Alerts: - eviction_count rate > baseline (e.g., >100/min) sustained 5m - cache_hit_ratio trending down- First 3 steps: 1. Confirm eviction metric and correlate with traffic/ingress spike. 2. Identify evicted key patterns (namespaces) and client operations contributing to churn. 3. Throttle write-heavy clients or rate-limit batch jobs.- Automated mitigation: Auto-scale cache cluster (add node or increase instance size) with rebalancing script to reduce evictions.

Spike in misses- Alerts: - miss_rate increases >X% vs baseline for 3m; hit_ratio drop - Backend error increase (origin load)- First 3 steps: 1. Check client-side caching behavior and recent deploys that change key patterns or TTLs. 2. Query cache logs for key prefixes with high misses; compare to backend request rate. 3. Temporarily enable cache warming for critical keys or serve stale with background refresh.- Automated mitigation: On detecting high miss spike, trigger async cache-warm jobs for top N hot endpoints and enable short-term longer TTLs for warmed keys.

Replication lag- Alerts: - replication_delay > SLO (e.g., >500ms / >X seconds) or replication backlog growing - replica lag metric increasing for >1m- First 3 steps: 1. Inspect replication stats (backlog size, network IO, CPU) on master and replicas. 2. Check network issues, disk IO, or GC pauses on affected nodes. 3. Promote healthy replica for reads if configured; divert traffic away from lagging replicas.- Automated mitigation: Automated failover/promotion for prolonged lag: if lag > threshold for T and health checks fail, promote standby and remove lagging node from rotation, with automated restart and re-sync job.

Notes:- Always notify owning service and run targeted throttles before structural changes.- Post-incident: collect heap/key dumps, client traces, and open RCA.

HardTechnical

33 practiced

Write SQL and application-level pseudocode to safely invalidate a cache key when a database row is updated. Consider race conditions where a read may occur between DB commit and cache invalidation and propose patterns to avoid serving stale data.

Sample Answer

Approach summary: keep DB as source of truth, ensure cache invalidation happens after DB commit, and avoid the window where a reader sees stale cache by using one or more patterns: 1) cache-versioning (store a row version in cache and DB), 2) transactional outbox/async invalidation, or 3) “double-delete” + short TTL as fallback. Below are examples.

SQL (add a version column and update in a transaction):

sql

BEGIN;
UPDATE items
SET data = $1, version = version + 1, updated_at = now()
WHERE id = $id;
-- Optionally insert into outbox for async invalidation
INSERT INTO outbox (topic, key, version) VALUES ('cache_invalidate','item:'||$id, (SELECT version FROM items WHERE id=$id));
COMMIT;

Application-level pseudocode (cache-aside with version check + outbox consumer):

python

# Writer: run DB transaction shown above, then return new_version

# Reader:
def get_item(id):
    cache_key = f"item:{id}"
    cached = cache.get(cache_key)
    if cached:
        # cached includes payload and version
        payload, cached_version = cached.payload, cached.version
        # fetch only version from DB to detect staleness (cheap)
        db_version = db.query("SELECT version FROM items WHERE id = ?", id)
        if db_version == cached_version:
            return payload
        # else fall through to reload
    row = db.query("SELECT data, version FROM items WHERE id = ?", id)
    cache.set(cache_key, (row.data, row.version))
    return row.data

# Outbox consumer (reliable async invalidation)
def outbox_worker():
    for msg in outbox.poll():
        cache.delete(msg.key)                 # safe after DB commit
        mark_outbox_processed(msg)

Patterns & reasoning:- Versioning avoids race: reader validates cached version against DB version; only hits DB for a small version check.- Outbox ensures invalidation happens after commit; reliable consumer deletes cache.- Double-delete (delete, sleep short, delete again) is weaker: use when outbox not available.- Always combine with short TTL and monitoring to bound staleness.Trade-offs: version check requires a cheap DB read; outbox adds complexity but scales and is reliable.

MediumTechnical

35 practiced

How can Bloom filters be used in front of caches or databases to avoid unnecessary DB lookups for non-existent keys? Explain false-positive impacts, memory trade-offs, and how you would rebuild/refresh a Bloom filter in production.

Sample Answer

Use case summary:Place a Bloom filter in front of a cache or DB to quickly test whether a key is “definitely not present.” If the filter says “no,” skip cache/DB lookup and return a miss (or negative cache). If it says “maybe,” proceed to cache/DB lookup as normal.

False-positive impacts:- False positives cause extra DB/cache lookups for keys that actually don’t exist. That increases read load and latency but does not cause incorrect data to be returned.- Cost: higher CPU/IO and possible SLO impact if the false-positive rate is too high. Choose target false-positive probability p to trade off these costs.- False negatives are impossible for a standard Bloom filter, so you won’t incorrectly drop existing keys.

Memory & parameter trade-offs:- m = - (n * ln p) / (ln 2)^2 bits where n = expected distinct keys, p = desired false-positive rate.- k = (m/n) * ln 2 optimal hash functions.- Example: for n=10M and p=1% you need ~9.6M bytes? (calculate precisely when planning) — lower p => linearly more memory.- Alternative: partitioned Bloom filters, counting Bloom filters (support deletions) — counting increases memory by factor for counters.- If keys are highly skewed in popularity, use a Bloom filter for the universe of possible keys (or negative cache for very hot non-existent prefixes).

Rebuild / refresh strategy in production:- Offline rebuild: periodically (or on changes) re-generate a new Bloom filter from the authoritative store snapshot. Build in background to avoid blocking.- Double-buffer/versioning: keep two filters A (active) and B (building). Atomically switch pointers or feature-flag the new version once ready. Continue queries against active until swap.- Incremental updates: for low-churn systems, insert new keys into a running filter; for deletes, either use a time-to-live for the filter and rebuild, or use a counting Bloom filter if deletes are needed (but accept memory/cost).- Sharded filters: build per-shard filters (by hash range or tenant) to reduce rebuild size and allow parallel rebuilds.- Consistency & rollout: deploy with a ramp, monitor false-positive-caused DB load and latency. Emit metrics: miss rate, filter hit/no-hit, rebuild duration, memory usage.- Safeguards: fallback logic that bypasses the filter if its failure causes service degradation, and alarms on abnormal DB read rates after swaps.

Operational notes:- Use RedisModule or native Bloom in RedisBloom for in-memory fast checks, or local in-process filter for ultra-low latency.- Monitor DB QPS correlated with "maybe" responses to tune p and rebuild cadence.- Test effects under load: simulate high rates of non-existent keys to ensure no amplification of incidents.

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.