A strong answer
I would first clarify read and write rates, freshness requirements, object size, geographic distribution, and the impact of stale data. I would estimate whether database load or latency is actually a problem before introducing another stateful component.
For a read-through or cache-aside path, define a key that includes every dimension that changes the response, including tenant or authorization context where appropriate. On a miss, the service reads the source of truth and fills the cache with a documented TTL. Updates can invalidate or replace the entry; concurrent fills and updates can race, so the policy must be tested.
I would define behavior for cache failure, a thundering herd, and hot keys. Metrics should include hit rate, stale responses where measurable, eviction, backend load, and tail latency. The cache must not become an accidental authorization boundary.
Follow-up direction
Compare TTL-only expiration with explicit invalidation and explain the freshness and operational trade-offs.