Caching keeps recently or frequently used results available in a faster storage layer. Its central purpose is to avoid unnecessary work: serve a result locally when it is still suitable instead of repeatedly calling a remote endpoint, database, or other dependency. Used well, it lowers request overhead, improves responsiveness, and reduces dependency load; during a partial outage, it can preserve performance by supplying a recent result. section 8.4.4 section 9.2
Choose the cache tier to match how quickly the data changes. HTTP caching with Cache-Control headers can let a browser or intermediary reuse a response without reaching the server. The same principle can extend across in-memory browser, CDN, server-side, and database caches. Each tier needs clear expiration rules: cached data is useful only while its age and update rate remain acceptable for the feature. section 8.4.4
Treat caching as a tradeoff between fewer remote calls and controlled retention:
- Cache data that is read repeatedly or frequently, especially when a remote call has fixed network overhead beyond its payload. section 8.4.4
- Match expiration to change frequency rather than treating all data alike. section 8.4.4
- Avoid allowing caches to become long-lived, oversized structures that retain more memory than the application actively needs. section 8.4.6
- Combine local retention with offline-first behavior when appropriate: keep recently used data and record actions locally, then synchronize in the background. section 8.4.4
- Use a cache as one resilience measure, not as a replacement for failure isolation, time limits, or graceful degradation. section 9.2
Profile lookup before database access
A simple cache lookup tells a readable story: first check whether a profile is already retained; if so, return it. Otherwise load the profile from the database, store it, and return it. This removes repeated database work for repeated requests, but the static map also makes retention a design concern: a cache needs a policy that prevents it from growing beyond useful data. section 8.4.6
private static final Map<String, UserProfile> CACHE = new HashMap<>();
public static UserProfile getUserProfile(String userId) {
if (CACHE.containsKey(userId)) {
return CACHE.get(userId);
}
UserProfile profile = loadProfileFromDatabase(userId);
CACHE.put(userId, profile);
return profile;
}
The listing makes the cache-as-fast-path pattern concrete: a map lookup returns an existing profile before the database loader runs, and a miss stores the loaded result for later reuse. section 8.4.6
Caching is most valuable when it is intentional. Reduce calls first by designing endpoints around the information a page needs; then cache at the layer that can safely reuse that information. Prefer a bounded, expiring cache over retaining data indefinitely, and weigh freshness requirements against the cost of another dependency call. section 8.4.4 section 8.4.6
