Caching Strategies and In Memory Storage Questions

Caching strategies for improving performance and reducing latency: HTTP caching semantics (Cache-Control, ETag, conditional requests, Vary), application-level caching with Redis and Memcached, in-memory data structures for caching, cache eviction policies (LRU, LFU, FIFO), cache invalidation strategies, TTL selection and trade-offs, and the consistency and performance implications of deciding what and when to cache.

EasyTechnical

51 practiced

Describe how common HTTP caching headers (Cache-Control, ETag, Last-Modified, Expires) affect caching behavior in a mobile app. Provide example header values and explain how a mobile client should handle conditional GETs (If-None-Match, If-Modified-Since) and 304 Not Modified responses to minimize data transfer.

HardTechnical

54 practiced

You observe a production regression: client cache hit rate dropped 40% after a recent release and battery usage on the app increased significantly. Outline a step-by-step debugging plan: data and instrumentation to collect, hypotheses to test (e.g., cache misconfiguration, increased cache churn, background jobs), code and backend checks, and a remediation strategy that minimizes user impact.

Sample Answer

**Situation overview & goal**Quickly restore cache hit rate and reduce battery impact while avoiding broad user disruption. Debug to identify root cause (client or backend) and deploy targeted remediation.

**1) Data & instrumentation to collect**- App-side metrics: per-device cache hits/misses, cache size, eviction count, entry TTLs, read/write latencies, network request counts, background job run counts. Tag by app build, OS, device model, user tier.- System metrics: CPU, wakelocks (Android), background execution time (iOS), battery drain per PID.- Network/backend: server response headers (Cache-Control, ETag), origin ingress rates, edge-cache hit rates.- Profiling traces: Android Energy Profiler / Battery Historian, Xcode Instruments (Energy log, Time Profiler), syslogs.

Instrument minimal, high-cardinality events using sampling and include timestamps and correlation IDs.

**2) Hypotheses to test**- Cache misconfiguration: client TTLs accidentally shortened or cache policy changed (e.g., disabled NSURLCache/OkHttp cache).- Increased cache churn: app now storing larger objects or more keys; eviction rate increased.- Content/headers change: backend started sending Cache-Control: no-store or varying ETags.- Background jobs or polling: a new periodic sync/background task causing frequent network calls and wakelocks.- Regression in serialization/keys: keys changed format preventing hits.- Memory pressure: OS trimming cache more aggressively due to memory leaks.

Prioritize by likelihood: recent release changes first, then backend.

**3) Code & backend checks**- Review recent commits/PRs touching caching, networking, background tasks.- Check client config: cache directory paths, max size, TTLs, OkHttp/NSURLCache initialization.- Validate request headers and cache keys (hashes, query params) in logs.- Inspect background scheduler changes (WorkManager/JobScheduler/BackgroundTasks) and any added periodic syncs.- Confirm backend response headers and CDN behavior; compare pre/post-release sample responses.

Reproduce locally with same build and traffic pattern; run energy and network profilers on representative devices.

**4) Tests to run**- A/B enable/disable cache-related changes via feature flag in staging.- Simulate high churn: large payloads and frequent writes to measure eviction.- Disable background jobs to observe hit rate/battery improvement.

**5) Remediation strategy (minimize user impact)**- Immediately toggle feature-flag to revert risky change (client-side) or rollback staged release.- If backend header change: revert server config or add compatibility layer to restore prior Cache-Control.- Hotfix: restore previous cache size/TTL defaults; avoid full app update if possible by using remotely configurable values.- Throttle or disable background syncs; convert to push-driven updates.- Deploy staged rollout/Canary for fix; monitor key metrics for improvement.- Communicate: internal incident notes, and if user-facing battery impact is severe, consider advisory.

**6) Prevent recurrence**- Add automated regression tests: cache-hit telemetry, energy budget checks in CI (instrumented device farm).- Require review checklist for changes affecting caching/background tasks.- Add alerting for sudden cache-hit or battery metric deviations.

Outcome-focused: isolate whether client vs server, use feature flags/rollbacks to minimize user impact, validate with profilers and telemetry, and harden processes to prevent future regressions.

HardSystem Design

56 practiced

Design a scalable push-based cache invalidation mechanism using FCM/APNs to notify mobile clients to refresh or remove specific cached content. The system must support 10M users, rate limits, and privacy constraints. Describe message format, topic vs per-device strategies, batching, security (auth), and how clients should safely process invalidations when offline or with delayed delivery.

Sample Answer

**Clarify goals & constraints**- Notify 10M mobile users to refresh/remove specific cached items using FCM/APNs.- Must respect provider rate limits, preserve user privacy (no PII in push), work with offline/delayed delivery, and be secure.

**Message format**- Small, opaque payload to avoid PII: - { "t":"inv", "cid":"<content_id_hash>", "v":123, "op":"invalidate", "exp":1650000000 } - t = type, cid = content id hashed (server-only map), v = version/tombstone, op = invalidate/refresh, exp = expiry epoch- Keep payload <4KB; prefer silent/background pushes (FCM data / APNs content-available).

**Topic vs per-device**- Topic (FCM topics / APNs broadcast via provider) for broad invalidations (e.g., "news:sports") — efficient fanout, low send count.- Per-device for user-scoped/private content or selective invalidation; required for privacy.- Hybrid: publish an invalidation to a topic that per-device subscriptions reflect (device subscribes to topic only for public items; private items use per-device).

**Batching & rate-limit handling**- Server-side fanout service: - Aggregate invalidations into batches by target (per-device list or topic) and time window (e.g., 200ms). - Respect provider QPS: shard senders, use token buckets and exponential backoff on 5xx / throttled responses. - Use multicast for FCM where possible; collapse multiple invalidations into one push that lists multiple cids.- For 10M users: use partitioned queues, parallel workers, and monitor provider error codes to throttle.

**Security & auth**- Use APNs JWT / FCM server keys or OAuth2 service accounts; rotate keys regularly.- Sign payloads / include HMAC key id when possible so client can verify authenticity before applying.- Do NOT include raw content or PII. Map hashed cid to content only on server or in secure local cache.

**Client processing (safe & robust)**- Validate message signature and exp.- Apply idempotent invalidation: check local cache entry v/version; only remove if v <= pushed v.- Coalesce: when receiving many invalidations, batch local refresh requests and use exponential backoff for fetches to avoid spikes.- Offline / delayed delivery: - On app foreground or network regained, client requests a delta sync: GET /invalidations?since=last_seen_v or GET /content/changed?user_id. - Store last_processed_version per content namespace; process pushes as hints, authoritative state from server via delta sync. - If push missed, server retains invalidation for window T (e.g., 7 days) and allows client to query changes by version.- UX: if content is critical, show stale indicator until refresh completes.

**Operational considerations**- Telemetry: track push success, token expirations, delivery latency, and client fetch rates.- Privacy: allow opt-out and honor platform Do-Not-Track; avoid correlation by not including user-identifying tokens in topics.- Testing: simulate throttling, token rotation, and long offline windows.

This design yields scalable fanout, privacy-safe payloads, robust client reconciliation (push-as-hint + server-authoritative delta), and operational controls for provider rate limits.

HardTechnical

56 practiced

Design an encrypted on-device cache for mobile that supports secure key rotation. The solution must allow offline access, use platform keystores, enable rotating encryption keys without losing access to cached data, and prevent attackers from extracting cached secrets. Describe key-wrapping/envelope-encryption and a migration plan for rotation.

Sample Answer

**Approach summary**Design an on-device envelope-encryption cache: each cached blob is encrypted with a randomly generated Data Encryption Key (DEK) using an AEAD cipher (AES-GCM or ChaCha20-Poly1305). Each DEK is wrapped (encrypted) with a Key Encryption Key (KEK) that is hardware-backed in the platform keystore (Android Keystore / StrongBox; iOS Keychain + Secure Enclave). Store ciphertext, DEK-wrap, key-version, nonce, and auth tag in cache metadata so offline access is possible.

**Key-wrapping / envelope-encryption**- For each item: - DEK = secure_random(256) - ciphertext = AEAD_Encrypt(DEK, plaintext, associated_data = metadata) - wrapped_DEK = KEK_wrap(KEK_version, DEK) via keystore API (signing/wrap APIs or RSA/OAEP or AES-KW using keystore-managed symmetric KEK)- Store: {key_version, wrapped_DEK, nonce, ciphertext, tag}- To read: retrieve wrapped_DEK → ask keystore to unwrap (requires user auth if configured) → decrypt ciphertext.

**Secure keystore usage**- Use hardware-backed KEKs where available; require user auth if policy demands.- Restrict KEK usage to wrap/unwrap only; never export KEK.- Protect metadata with integrity (AEAD associated data includes item id & version).

**Rotation & migration plan**- KEK rotation generates new KEK in keystore (new key_id/version).- Two migration strategies: 1. Eager rewrap: iterate cached entries, unwrap DEK with old KEK, rewrap with new KEK, update key_version atomically (use temp file + rename). Best for small caches or on background task when online/idle. 2. Lazy rewrap (recommended for large/offline caches): on read if key_version != current -> unwrap with stored KEK (keystore can still unwrap old KEK if retained), rewrap DEK with current KEK and update stored metadata. Optionally schedule background rewraps.- Maintain backward unwrap ability: keep old KEKs in keystore until all wrapped_DEKs rewrapped or old KEKs scheduled for deletion with grace period.- Record rotation events in secure audit metadata.

**Attacker resistance**- Hardware-keystore prevents KEK extraction.- AEAD prevents tampering; per-item random nonces prevent nonce reuse.- Use per-device keys (no shared secrets), optional user authentication gating.- Protect cache storage with filesystem protections and obfuscation; avoid storing plaintext or raw DEKs.

**Operational notes**- Use versioned metadata, atomic updates, retry-safe background jobs.- Test rotation under low battery/offline, ensure graceful fallback and predictable key deletion policy.

EasyTechnical

45 practiced

Explain the "stale-while-revalidate" pattern and describe how you would implement it in a mobile app's networking layer. Describe the UI behavior you would adopt so users see fast content but also eventually get fresh updates without jarring UI refreshes.

Unlock Full Question Bank

Get access to hundreds of Caching Strategies and In Memory Storage interview questions and detailed answers.

Join thousands of developers preparing for their dream job.