Client-side versus server-side caching

01Where is the saved copy?

A browser loads a logo and a signed-in user's profile. Ask where a reusable copy is found:

1. Client cache: a usable copy in the browser or mobile app can answer before any network request.
2. Server-side cache: the browser still sends a request, but an application cache, reverse proxy or nearby delivery cache may answer without reading the origin database or file store.
3. Several layers: each has its own key, allowed age and update path. Removing one copy does not automatically remove the others.

Also distinguish HTTP caching from custom application storage. A browser HTTP cache follows HTTP rules. Application code can separately write data into memory or offline storage. A service worker is browser code that can intercept requests and maintain another cache; HTTP directives do not automatically control every such custom copy.

List the actual stored copies, especially on logout or account switch. A server-side deletion cannot universally erase files already downloaded to a user-controlled device.

02Reuse, storage, and validation are separate

Choose three separate things: whether a response may be stored, when a stored response may be reused, and when it must be checked again.

For ETag validation:

1. The server returns a response with a tag identifying its version.
2. When reuse requires validation, the browser sends that tag with its request. The server checks the caller’s permission before confirming any private response; a matching old tag cannot authorize a revoked user.
3. If unchanged, the server confirms reuse without sending the full body again.
4. If the caller still has access but the bytes changed, return the new body and tag. If access was revoked, deny the request instead of validating the old private copy.

These are ordinary unqualified directive meanings; combinations have additional rules. Apply privacy and retention policy to custom offline writes too. A no-store HTTP response does not repair code that deliberately saves the same invoice elsewhere.

03Worked example: public assets and account statements

Follow a shared device through repeat visits and account changes:

1. The browser requests logo-v3.svg. A shared delivery cache may fetch it once from the origin; the browser may then store its own permitted copy.
2. The next visit reuses a fresh browser copy. No network request occurs for that resource, so CDN logs do not count every local use.
3. The shop changes the logo. Publish logo-v4.svg and update page references. Purging version 3 on the server does not necessarily remove a fresh browser version 3.
4. Account A opens a profile. If custom storage uses only the key profile, switching to B can display A's record. Include account identity in the key or isolate/clear the storage on switch.
5. A private invoice is requested. Check permission and prevent shared reuse. If local persistence is inappropriate, use no-store and avoid custom offline saving as well.

Compare what each optimization saves. Validating an unchanged 50 KB profile can save roughly 50 KB of body transfer, but still takes a network and server validation trip. A fresh browser hit avoids that request; a server-side hit saves some origin work while retaining the client-to-cache trip.

Permission revocation can control future requests. It cannot guarantee erasure of every byte already saved on an external device. State that limit when promising private delivery.

04Choose keys and freshness at each layer

Set policy at every actual copy:

• Public unchanging assets: versioned URLs make long reuse practical when pages discover new references after changes.
• Private account data: isolate identities and define account-switch/logout cleanup for custom stores.
• Server caches: include fields that change the response, such as language, size or identity where required.
• Freshness: coordinate allowed ages. A browser permitted an hour of reuse defeats a promise that a server purge alone makes profiles current within one minute.
• Offline use: decide intentionally which private data may persist and for how long; do not assume HTTP settings govern all code paths.

In the interview, mark which hit avoids a network request, which avoids an origin read and where permission is checked. Then switch accounts and revoke access. These traces expose errors that a repeated public-logo request will not.