Caching Strategies Thread
- Shalini Goyal shared six caching strategies drawn from her Amazon system-design interview experience. - Her thread covers patterns such as Cache-Aside and Write-Through, plus trade-offs observed in production. - The notes give practical examples and decision points useful for system-design interviews and engineering portfolio write-ups. (x.com)
Caching is a speed trick with a catch: store hot data in memory, answer in milliseconds, and then spend the rest of the design managing stale copies. (hellointerview.com) Shalini Goyal said her notes came out of an Amazon system-design interview and grouped six common patterns engineers are expected to explain, including Cache-Aside and Write-Through. Her post framed them as interview material tied to production trade-offs, not just textbook definitions. (x.com) The basic idea is straightforward. A database read might take about 50 milliseconds, while an in-memory cache read can land around 1 millisecond, a gap Hello Interview uses to show why Redis or Memcached often appears early in system-design answers. (hellointerview.com) Cache-Aside, also called lazy loading, is the pattern Amazon documents for Memcached: the app checks the cache first, falls back to the database on a miss, then writes the result into cache for the next request. Amazon says that keeps unused data out of memory, but every miss still pays the database penalty. (docs.aws.amazon.com) Write-Through takes the opposite posture on freshness. Oracle says the write does not complete until the cache has also persisted the update to the backing store, which cuts stale reads but adds latency to every write path. (docs.oracle.com) That trade-off is why interview answers usually split by workload. Hello Interview says Cache-Aside is the default answer for read-heavy systems, while write-through is less common because it needs tighter cache integration and still leaves consistency edge cases to discuss. (hellointerview.com) Other patterns fill in the gaps. Oracle documents Read-Through, where the cache loads missing data automatically, plus Refresh-Ahead, which reloads entries before they expire to reduce user-visible misses. (docs.oracle.com) Amazon’s cache guide adds a practical warning on failures: when a cache node is replaced with an empty one, the application should still work, but latency rises because misses flood the database until the hot keys are rebuilt. That is the production version of the interview phrase “cache miss storm.” (docs.aws.amazon.com) A solid caching answer, in other words, is not “use Redis.” It is picking the pattern that matches the read-write mix, the freshness requirement, and what breaks when the cache is empty. (hellointerview.com)
