Skip to content
System design course
Ch.3 · Trade-offs that define a design·concept ·5 min read

Server-side vs client-side caching

Cache near the data or near the user — one you control and share across everyone, the other eliminates the request entirely but is yours to invalidate no more.

Where do you put the cache

Both store responses to avoid recomputation, but location changes everything:

  • Server-side — a cache you run (Redis/Memcached, a reverse-proxy/CDN cache) between your app and database.
  • Client-side — a cache on the user’s device (browser HTTP cache, localStorage, a mobile app’s store).

Server-side caching

  • Shared across all users, so one user’s miss warms the entry for everyone — great hit rates for common data.
  • You control it: you can invalidate, update, and size it precisely; data stays inside your trust boundary.
  • Costs: the request still crosses the network to you; you operate and pay for the cache.
  • Best for: hot shared data (popular posts, computed feeds, DB query results) and offloading the database.

Client-side caching

  • Fastest possible: a hit means no network request at all — lowest latency and zero server load.
  • Per user: not shared; each device caches its own copy.
  • Costs: you can’t easily invalidate it (the data is on someone else’s device) — you rely on TTLs, Cache-Control/ETag headers, and versioned URLs; not for sensitive or rapidly-changing data.
  • Best for: static assets, a user’s own rarely-changing data, anything where occasional staleness is acceptable.

The side-by-side

Server-sideClient-side
LocationYour infrastructureUser’s device
Shared across usersYesNo
Invalidation controlStrongWeak (TTL/headers)
Saves network hopNoYes
Saves server loadPartiallyFully (on hit)

Use both — the layered cache

These aren’t rivals; they’re layers. A request ideally never leaves the device (client cache), else is served near the user (CDN), else from your app cache (Redis), and only on a full miss hits the database:

browser cache → CDN → app/server cache → database

Each layer absorbs traffic so the next sees less.

The interview cue

“Static assets and the user’s own settings cache client-side with long TTLs and versioned URLs — zero server hit. Shared hot data (trending posts, query results) caches server-side in Redis where I can invalidate it on write. Together with a CDN it’s a layered cache, each tier shielding the next.” Naming the invalidation trade-off — strong control server-side, TTL-only client-side — is the signal.