Cache = trade off speed vs freshness
Caching patterns

When to use caching

Cache eviction policies

Use cases

Hot search terms

You can also use the CDN as a cache for api results. Short term. Ok if only a few
Consider how often it changes, how long it's cached.

If you cache it, then you can't personalise it. Same with html pages, you can cache a home page only if it's the same for everyone (at least for a certain region per CDN).

Number of urls could become expensive if lots of query params

Reduce load on main db

For read heavy systems, you can reduce load on db by introducing a key value cache in front. Especially for data that doesn't change often, then you don't have to invalidate cache often
That allows keeping just one postgres for example. But be wary of single points of failure if the cache dies for example, be ready to have more DBs for reads anyway

Ways to cache

In-memory caching

In-memory caching (or memoization) works in some scenarios, for example for caching all data in a table if the table is quite small (like a small table of retailers).

Edge cases

Database requests burst when TTLs expire

If you cache on service start and all servers start at the same time, it'll burst the db in requests.
Or if all TTLs expire at the same time.
To remediate, you can use "cache warming" where you query the db before the cache expires.

Hot caches

If a key is requested a lot, you can:

• load balance it across nodes
• keep an in-memory cache for hot keys in apps/clients
• be more granular in the cache key
• request coalescing (if multiple requests are the same, trigger only one and return the result for all clients)

Resource

Youtube - Hello Interview – Caching in System Design Interviews w Meta Staff Engineer
Youtube - Maddy Zhang – 900+ hours of Learning System Design in 9 Minutes