Compare cache-aside, read-through, write-through, and write-back
Reported in Snap USA engineering loops. Caching patterns for system design and backend performance tuning.
Interview scenario
Often asked in Snap on-site or virtual loops at US offices (Bay Area, Seattle, NYC, Austin, and remote US). Prepare a clear spoken answer plus key trade-offs.
Model answer
Try answering aloud first
Cover trade-offs, structure, and a concrete example before revealing the baseline response.
How to frame this at Snap: Connect your answer to measurable impact, clarity of thought, and trade-offs the team cares about. Below is a strong baseline response you can adapt with your own project examples.
Cache-aside (lazy loading): App reads cache first; on miss, loads DB, populates cache. Writes update DB then invalidate cache. Simple and common; risk of stale reads if invalidation fails.
Read-through: Cache library loads from DB on miss—app always talks to cache layer. Centralizes loading logic.
Write-through: Writes go to cache and DB synchronously—consistent but higher write latency.
Write-back (write-behind): Writes hit cache first; async flush to DB—fast writes, risk of data loss on crash.
Discuss TTL, eviction (LRU/LFU), stampede protection (single-flight locking), and CDN vs application vs database buffer cache. Pick pattern based on read/write ratio and consistency requirements.
Discussion
Comments (0)
Share how this question came up in your loop, or add tips for others preparing.
Log in to comment on this question.