Client cache

Client caches store responses in browser memory, disk (IndexedDB), or mobile app storage to reduce latency and offline gaps. Cache safe, user-specific or public data with explicit TTLs, cache keys tied to resource versions, and invalidation on logout or permission change.

Optimistic updates improve perceived speed but need rollback on conflict. Respect privacy: do not cache sensitive tokens or PII longer than necessary. HTTP cache headers complement application-level client stores.

On interviews: describe cache key design for a profile page, TTL choice, and what happens after a failed write with optimistic UI.

Common pitfalls: stale permissions after role change; caching personalized data in shared CDN; no cache bust on deploy breaking SPAs.

The trade-off is flexibility versus complexity—know when the simpler path is enough.

Checklist:

• Define cache keys and TTL per resource.
• Invalidate on auth and permission changes.
• Handle optimistic update rollback.
• Separate public versus private cached data.