What is caching, and what are the common caching strategies?

Where can caching happen?

In the browser, at a content delivery network near the user, in the application’s memory, in a shared cache such as an in-memory store, and in the database itself. Each layer trades reach and freshness differently.

What is cache-aside?

The application checks the cache first. On a miss it reads the database, stores the result in the cache and returns it. When the data changes, the application deletes or updates the cached copy. It is the most common pattern.

What are write-through and write-behind?

In write-through, every write goes to the cache and the database together, so the cache stays fresh. In write-behind, writes go to the cache first and are saved to the database later, which is fast but can lose data if the cache fails.

How do you keep cached data fresh?

Set a time to live so entries expire, and invalidate an entry when its source changes. Use both: the expiry limits how stale an entry can get if an invalidation is missed.

What can go wrong?

A popular entry expiring can send many requests to the database at once, called a stampede, which a single refresh or a stale copy can prevent. Personal data cached where others can read it, or keys that omit something that changes the value such as language, serve the wrong content.

When should you not cache?

When data must always be current, such as an account balance at the moment of payment, or when the cost of a wrong value is high. Make sure the system still works, if slower, when the cache is empty.

IICTP is an independent technical credentialing body.