Which of the following is NOT a benefit of client-side caching?

Server processing is not eliminated; caching prevents repeating the same server request but doesn't change server-side logic. Other options are true benefits.

In the context of caching, what does 'cache miss' mean?

A cache miss occurs when data is requested but not found in cache, necessitating a network request. Other options describe different failure scenarios.

Which scenario benefits MOST from client-side caching?

Static, rarely-changing data like country lists is ideal for caching. Real-time data requires frequent updates and sees minimal caching benefit.

What is the primary advantage of the Stale-While-Revalidate (SWR) strategy?

SWR serves cached data immediately for responsiveness, then refetches in background for freshness. It balances speed with data currency.

In React Query, what does `staleTime: 0` mean?

`staleTime: 0` (default) marks data as immediately stale, triggering background refetch on next access while still serving cached data.

When should you set `staleTime` to `Infinity`?

`Infinity` prevents refetching for truly static data. Using it for dynamic data risks serving outdated information.

What is the relationship between `staleTime` and `cacheTime`?

`staleTime` determines when a cached item is considered stale and needs revalidation. `cacheTime` controls garbage collection of unused cache entries.

You have a user profile page with `staleTime: 5min` and `cacheTime: 10min`. User visits the page, waits 6 minutes, and returns. What happens?

After 6 minutes, data is stale but still in cache. SWR serves cached data immediately while refetching in background.

What does the `isFetching` flag indicate in React Query's useQuery hook?

`isFetching` is true whenever a fetch (initial or background) is happening, useful for showing refresh indicators in SWR flows.

Why is JavaScript `Map` preferred over a plain object `{}` for autocomplete caching?

Map supports non-string keys and has `.size` property, plus guaranteed insertion order. Objects only support string/symbol keys.

In the autocomplete example, why is debouncing used?

Debouncing delays cache lookup/fetch until user stops typing, eliminating redundant requests for intermediate keystrokes.

What happens if you don't set an expiry time for autocomplete cache entries?

Without expiry, cache grows unbounded with stale suggestions. Users may see outdated products/data if search results change.

You're caching search results for 'iphone'. User later searches for 'IPHONE' (uppercase). What should happen?

By normalizing queries with `.toLowerCase().trim()`, 'iphone' and 'IPHONE' map to the same cache key, enabling hits for case variations.

Why does an in-memory Map cache lose all data when the page is refreshed?

In-memory caches exist only during page session. Refresh loads new JavaScript context with fresh variable state.

How should you handle the scenario where an autocomplete cache grows unbounded over a long user session?

Set expiry timeouts and/or cap cache size using LRU or similar strategy to prevent memory exhaustion in long sessions.

What is the primary benefit of an LRU cache compared to a plain `Map`?

LRU bounds memory usage with fixed capacity. When full, least recently used items are evicted, unlike unbounded Map.

In LRU cache implementation, what is the purpose of the doubly linked list?

Linked list maintains access order with O(1) node removal/insertion, enabling efficient LRU tracking and eviction.

Given LRU cache with capacity 3, after operations `put(a,1)`, `put(b,2)`, `put(c,3)`, `get(a)`, `put(d,4)`, what keys remain in cache?

After `get(a)`, 'a' becomes MRU. When 'd' is added and capacity is full, 'b' (LRU) is evicted. Remaining: a, c, d.

Why use a HashMap in LRU cache implementation alongside the linked list?

HashMap enables O(1) retrieval of cache nodes by key. Without it, finding a node would require O(n) list traversal.

In LRU implementation, what happens when you `get()` an existing key?

Access updates MRU status. Node is unlinked from current position and inserted after head, reflecting recent use.

What is a potential performance problem with LRU caches in certain access patterns?

LRU thrashing occurs when access pattern (e.g., sequential access larger than cache) causes repeated evictions/misses.

What is the main difference between `localStorage` and `sessionStorage`?

localStorage persists indefinitely (cross-session), sessionStorage is scoped to single tab and cleared on tab close.

Why must data be converted to JSON string before storing in localStorage?

localStorage/sessionStorage only store strings. Complex types must be JSON.stringify'd; retrieve with JSON.parse.

You store an authentication token in localStorage. What security risk does this introduce?

localStorage is accessible to any JavaScript running on the page. XSS vulnerabilities allow attackers to read and steal tokens.

You use sessionStorage to store a user's current search filters. The user opens a new tab. Can the new tab access the filters?

sessionStorage is per-tab/per-window. Each tab has its own isolated sessionStorage; no cross-tab sharing.

What happens if you try to store 50 MB of data in localStorage?

localStorage quota is ~5-10 MB per origin. Exceeding it throws QuotaExceededError; no automatic eviction occurs.

How can you detect when a user clears localStorage from browser settings?

If localStorage is cleared externally, subsequent checks will show `.length == 0`. Storage events notify about cross-tab changes.

You need to store user preferences that should sync across all open tabs. Which storage should you use?

localStorage is shared across tabs. Listen to 'storage' events to detect changes in other tabs and update UI accordingly.

What is a helper function useful for when working with Web Storage?

Helpers abstract away JSON.stringify/parse and enable features like expiry checking without boilerplate code.

Client-Side Caching — System Design Concept

Before diving into specific strategies, let's understand why caching is important.

Every time your browser fetches data from a server, it involves:

Network latency (time to travel back and forth)
Server processing time
Bandwidth consumption

Without caching, every single interaction triggers this full round-trip. With caching, the browser can serve previously fetched data instantly from local storage, dramatically improving user experience.

Real-world analogy: Imagine you work in an office and your colleague asks you the WiFi password. You walk to the IT room, get it, and come back. The next day, another colleague asks the same question. Instead of walking to IT again, you just tell them the password you already memorized. That "memorized password" is your cache.

Without Caching: With Caching: User Action User Action | | v v Network Request ------> Server Check Cache | <------ Hit? --> Return instantly | | v Miss --> Fetch from Server Render Data