The realm

An in-memory cache — also called a local cache or in-process cache — is data your application keeps in its own memory, inside the running program.

A process is one running copy of your program. When you start your server, that is a process. It has its own memory that no other program can see.

This is the fastest cache that exists. There is no network. There is no serialization — the object in the cache is a real object in your program, ready to use. A hit takes roughly 100 nanoseconds.

What you can hold here

You now have somewhere very fast to put things. The question is what to put there.

Inside your own process, two different kinds of thing are worth keeping — and they carry completely different risks.

Work you already did. A calculation, a parsed file, a rendered fragment. The inputs are still sitting right there in your program; you simply do not want to do the arithmetic twice. This can only go stale if the inputs change, and you control the inputs.

Data that came from somewhere else. A product row from the database, a response from another service. This copy can become wrong at any moment, because somebody else can change the original without telling you.

The first is nearly free of risk. The second is where Lesson 11 comes from.

Start with the safe one.

Memoization

Memoization is caching the result of a function so that calling it again with the same inputs returns the stored answer instead of recomputing it.

calculate_shipping(weight=2.5, zone="EU", express=false)
   → first call:  runs the calculation      12ms
   → second call: returns the stored answer  0.0001ms

The inputs form the key. The return value is the value. It is Lesson 2's key rule applied to a function signature — and it has the same failure mode. If the function secretly depends on something not in its arguments (today's date, a config setting, a database row), then that hidden input is missing from your key, and you will serve the wrong answer.

Memoization is only safe for functions where the same inputs always produce the same output.

The costs

Memory is shared with your application. A local cache lives in the same memory your app needs to run. An unbounded cache will consume it all and crash the process. Always set a maximum size — how the cache decides what to remove when it hits that limit is Lesson 10.

The cache dies with the process. Restart, deploy, crash, or scale down, and it is gone. Every deploy gives you a cold cache and the full cold-start problem from Lesson 2.

It does not scale with your data. A local cache can hold what fits in one machine's spare memory. That is a hard ceiling.

Redis, introduced carefully

Redis is a separate program that stores key-value data in memory and is reachable over a network. Many applications can talk to the same Redis instance.

It is important to be precise about this, because the terms get muddled constantly:

Redis is roughly 5,000 times slower than a local cache. It is also roughly 200 times faster than a cross-continent request, and — the reason it exists — it is shared.

Both belong to the application layer, but they have different costs: a local cache stays inside one process; Redis is shared over the network.

What belongs in a local cache

Things that are the same for every user, cheap to rebuild, and harmless if two servers are a few seconds out of step with each other.

• Feature flags — is the new checkout switched on?
• The country list behind a dropdown
• The navigation menu and category tree
• Currency conversion rates
• An expensive calculation you keep repeating with the same inputs

If your server restarts and loses all of it, nothing breaks. It rebuilds on the next request and the user never knows.

What does not belong here: anything about one particular person. Your process serves thousands of users at once, and a key that forgets to say which of them will hand one customer's data to the next.

At the Storefront

Memoize the shipping and price calculations. Keep the category tree in a local cache with a 5-minute TTL.

Leave the product data alone for now. You are about to find out why.