- Beginner
- Caching
Where it shows up in real systems
-
In-memory cache
The hit ratio depends on how much of the working set fits in memory, the TTL and the eviction policy. If the cache goes down or is flushed, every read falls on the database at once: plan for that stampede. Write-behind is fast but loses writes if a node dies without a replica.
In production: Redis (Amazon ElastiCache, Azure Cache), Valkey, Memcached, Dragonfly
-
In-process cache
No network hop, so it is the fastest cache possible, but each instance holds its own copy: memory is duplicated and invalidation is hard, so instances can disagree for up to the TTL.
In production: Caffeine (Java), Guava cache, lru-cache (Node.js), functools.lru_cache
See it break, then fix it
Build an architecture, send it a day of traffic and outages, and learn why it holds or fails. Free to start.