<- back
# Caching: Faster by Remembering
Posted on Oct 3, 2026
A cache is just a store of data that provides a faster read or write time for your data. Instead of asking the database the same question over and over, you keep the recent answer in the cache which is usually much faster.
Let's imagine that your app has a profile page which displays the users profile information, now querying your database for this data which does not change often is quite expensive. A possible option to solve this problem is to cache this data on the users localstorage with a TTL according to the applications needs.
## Try it
For this example, a cache hit equals a 1ms read time and a database read takes 35ms.
1. Why cache size matters
Request a key. The leftmost cache slot is the most recently used and the rightmost one is the least recently used which would get replaced first.
Cache
Note: a repeated key becomes a hit, while a new key is a miss and has to visit the database. A larger cache can keep more useful answers around, which is how it improves the hit rate over time.
2. Why hit rate matters
This comparison uses 10,000 read requests.
Average response time: 7.8ms (4.5x faster than no cache)
Where requests go
Average time compared to no cache (35ms)
Capacity tells us how many items can be stored at once. The hit rate is the percentage of reads that actually find their answer there. A bigger cache size is usually the solution however maintaing a high hit rate is also very important
## Why that matters
At an 80% hit rate, 8,000 of those 10,000 requests skip the database. This results not only in a faster load time but also indicates that the database has to do less work.
Caches are particullarly useful when changes are rare. Almost every application you interact with daily uses some type of caching. Social media apps use caching for popular posts, streaming services store frequently visited episodes/shows in caches, etc.
## TTL (Time to Live)
When the original data changes, you need to update or remove the old cached answer. A common simple approach is a TTL (time to live): keep an answer for, say, five minutes, then fetch it again.