Application Cache

The Workhorse Tier

 application cache = explicit key-value store in your service path:
   Redis / Memcached / managed equivalents

 [app] ──GET user:912──► [ Redis ] ──hit: 0.5ms──► return
            │ miss
            ▼
         [ Postgres ] ──45ms──► SET user:912, TTL 300s ──► return

 vs browser/CDN layers: this one YOU program — keys, values,
 TTLs, invalidation are all your code's decisions.

What Lives There

Pattern	Example	Notes
Entity cache	user:912 → JSON	The bread-and-butter
Query result	trips:city:nyc:active	Careful: invalidation pain
Computed object	fare:o:d:h:t → price	Expensive derivation saved
Session store	sess:abc → user data	Statelessness enabler
Rate counters	rl:user:912 (INCR)	Atomic ops shine
Locks	lock:trip:77 (SET NX)	Distributed coordination
Hot lists	trending (ZSET)	Sorted-set superpowers

Redis vs Memcached

 Memcached: pure multi-threaded KV. dead simple. strings only.
 Redis    : single-threaded core (mostly), RICH structures:
            hashes, sorted sets, streams, pub/sub, Lua scripting,
            persistence options, replication/cluster

 default choice today: Redis — the data structures eliminate
 whole classes of "cache + side table" complexity.
 Memcached persists in legacy fleets and pure-string farms.

Data Structure Superpowers

 modeling IN the cache beats JSON blobs for hot paths:

 leaderboard:  ZADD board score user     / ZREVRANGE board 0 9
 sessions:     HSET sess:a field val     (partial updates)
 uniqueness:   SADD seen:day ids         (membership tests)
 rate limit:   INCR rl:u:912 + EXPIRE    (atomic counter+TTL)

 each replaces fetch-modify-write races with single atomic ops.

Operational Realities

 memory management:
 - set maxmemory + eviction policy (allkeys-lru usually)
 - TTL EVERYTHING unless deliberately persistent
 - watch fragmentation; big values hurt more than many small

 failure modes to plan:
 - cache restart = cold = origin stampede (warming lesson)
 - network blip to redis: fail OPEN (serve from source) or CLOSED?
   reads: open. auth-critical decisions: careful.
 - never let a cache outage take the site down;
   caches are accelerators, not dependencies... except sessions,
   which ARE dependencies — replicate those.

Sizing With Numbers

 hot-set estimate method:
   top N entities × avg object size × safety factor

 RideShare drivers online: 500k × 2KB ≈ 1GB working set
 active trips:             200k × 4KB ≈ 800MB
 sessions:                 2M   × 1KB ≈ 2GB
 ─────────────────────────────────────────────
 ~4GB hot set → one 8GB node with room; cluster later.

 sizing caches is THIS arithmetic, not vibes.

Interview Framing

“Add caching” scores when specific: engine chosen with reason (“Redis — need ZSETs for leaderboards”), key scheme shown, TTLs per entity class, size estimate computed, fail-open stance stated. Naming what you would NOT put there (source-of-truth financial state) completes the seniority picture.