Comparison
Cache-asidevsRead-through cache
Cache-aside
you check the cache, miss, go and read the database yourself, and write the value back before you return it.
The application owns the cache: on a miss it loads from the store and populates the cache itself. It is the usual default because the cache can go down without taking reads with it, and because nothing is cached that nobody asked for. The costs are that every miss pays database latency plus a write, and that two requests missing the same key at the same moment both hit the database.
Full entry →Read-through cache
you ask the cache for the key and the cache itself is the thing that goes and loads it when it is not there.
The cache sits inline in front of the store and fetches missing entries on your behalf, so application code only ever talks to the cache. That keeps loading logic in one place and makes stampede protection something the cache can implement once. The price is a hard dependency: if the cache is down, reads are down, because there is no path around it.
Full entry →