The detailed guidance and illustrative examples below are in English. All example business records are fictional.
Where Redis fits
A measured caching or short-lived coordination need with a clear source of truth.
When to choose another approach
No percentage improvement is assumed. Cached prices, permissions or stock can become stale.
Worked example and evidence
Fictional catalogue: cache product descriptions, invalidate them on edit and reload from the database on a miss. Confirm authoritative stock when placing an order.
What you need to supply
Slow-request evidence, cache keys, expiry/invalidation rules, authoritative store and outage behaviour.
What acceptance should demonstrate
Measure hits and misses, edit cached data, empty the cache and simulate an unavailable cache without corrupting orders.
Running costs and responsibilities
Assign memory limits, eviction review, credentials, hosting and recovery. Define whether data must persist.
Technical scope to confirm
Persistence, eviction and expiry choices depend on whether Redis stores disposable or durable application state.
A proposal should identify the systems and data, direction of sync, access feasibility, failure handling, named owners and included deliverables. Listing this technology does not imply a prebuilt connector, vendor partnership or included feature.
What happens when the cache is empty or unavailable?
Use the agreed source-of-truth path, with capacity limits or a clear degraded response. Do not assume the database can absorb unlimited cache misses.