
If you use the same book every day, you might keep it on your desk instead of walking to the library each time. A cache works in a similar way: it keeps a temporary copy close to where it is needed.
A browser can cache an image or stylesheet. On your next visit, it may load that file from your device instead of downloading it again. A server can also cache a result that would otherwise take a slow database query to calculate.
Example: a dashboard shows the same public list of countries to every visitor. The server could keep that list in a cache for a short time instead of asking the database on every page load.
A cache is useful only when the saved copy is still safe to use. If the country list changes, the app needs a way to refresh or remove the old copy. This is called cache invalidation.
Some data should not be shared through a public cache. A private account page, for example, must not show one person’s information to another person.
A cache rule can say how long a copy may be reused, which changes remove it, and whether it belongs to one user or everyone. Measure the app before adding a cache; sometimes a simpler database query is enough.
Caching can make an app faster by avoiding repeated work, but it adds a freshness question: how will the app know when the saved copy needs an update?