Should I cache everything?

No, and saying so counts in your favour. A cache earns its complexity when data is read far more often than it changes and costs something to produce. A well indexed query against a table your database already holds in memory is fast, and a cache in front of it adds a staleness problem and a new way to fail for no gain.

Why delete the key on a write instead of updating it?

Because a delete cannot arrive in the wrong order. If two edits race, one order in the database and another in the cache leaves the cache holding the loser until it expires. A delete has no value left to be stale, so the next reader rebuilds from the source. It costs one extra read on something that was about to be read anyway.

What happens if Redis goes down?

Every read misses and falls through to the database, so your system stays up and gets slow. Whether it survives depends entirely on whether the database can absorb the traffic the cache was absorbing, which is worth testing before you find out during an incident. A cold cache after a restart is dangerous for exactly the same reason.

How do I choose the time limit?

Work backwards from how wrong the data is allowed to be, because the limit is the longest anyone can see an old value. Thirty seconds for a stock count, an hour for a description, and probably no cache at all for an account balance. Then add a few random seconds so keys stored together do not all expire at the same moment.

Cachingchapter 1 of 8 · 6 lessons

How Caching Works

Start here. What a cache is, why a database needs one, and where one can live.

← All chapters View in cheatsheet

Your app has one job. Someone opens a product page, your server asks the database for that product, and sends it back. It works, it is fast, and you ship it.

Then the app catches on. Last month you served ten thousand requests a day. This month it is a million. You have not changed a line of code, but pages that took 40 milliseconds now take 400, and the database is busy all afternoon.

Nothing is broken. Your database is doing exactly what you asked, a million times over. Most of those times it answers the same question about the same product and returns the same answer. That repetition is where a cache comes in.

Lessons

6 in this chapter

The Problem a Cache SolvesYour database is not doing hard work. It is doing easy work a million times, and charging full price for each one.2 min
What a Cache IsA copy of your data kept somewhere faster, which you are allowed to lose.3 min
Where Caches LiveFour places, from the user's phone to a server your whole fleet shares.3 min
Reading From a CacheAsk the cache. If it is empty, ask the database and put the answer back.2 min
Writing Through a CacheThe database is the truth, so every change has to decide what happens to the copy.2 min
How Caches FailStale copies, full memory, everyone missing at once, and one key that gets all the traffic.3 min