Caching: when not to cache

Three defaults: define the input-output contract, then the error branches, then the happy path. An implementation without error handling is not finished.

Task: Added a cache and users complain about stale data.

[Before you start, do three things]
1. Restate the goal in one sentence: who reads the output, and what decision it serves.
2. If I have not given you the following, ask me. Do not assume:
   - update frequency and tolerable staleness
   - read-heavy or not
   - can invalidation be precise
3. Say how you plan to do it (at most 5 steps) and wait for my go-ahead.

[Go through each of these]
- estimate the gain first; skip when reads are few
- state invalidation: TTL, explicit delete, version
- name what must not be cached: balance, stock, permissions
- guard against penetration and stampede

[Process]
1. State the contract: inputs, outputs, errors, side effects
2. List every error branch and boundary first
3. Then the happy path, one responsibility per function
4. Test key paths: one normal, two failure cases
5. State when this code would fail

[Output]
Contract, errors, happy path, tests, failure conditions.

[Do not]
- Never ignore an error return
- Never swallow exceptions
- No magic numbers; name them
- Do not log-and-continue instead of returning an error