Choose the cache policy from freshness, origin load and tail latency together
One policy gives the highest hit rate by serving older data. Another is fresh but overloads the origin at expiry. The team needs a decision tied to the actual contract.
- Focused work estimate
- 5h + prerequisites
- Priority in the scenario
- High
- Engineering practice
- Performance tradeoffs · Resilience testing
Estimated field mix
- Performance engineering50%
- Site reliability30%
- Quality engineering20%
Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence.
Review it, then add it to your workspace.
The board opens an editable draft; nothing is saved until you confirm it. Sign-in and workspace permissions apply, and Demo boards remain ephemeral.
Project context
A fictional equipment-rental service caches availability summaries. A campaign sends repeated reads, while stock updates and shared expiry times create bursts against the origin. Build a local origin stub and cache-backed read API using synthetic depots and products.
Setup prerequisites
- Create a deterministic local availability origin and Redis-backed reader with synthetic tenant, depot and product data.
- Use a seeded hot-key distribution and controlled time; record cache capacity, TTLs, runtime and machine limits.
Preceding work
Complete these dependencies, or supply their agreed outputs before taking this ticket.
- PCACHE-101 · Specify which availability responses may be reused
- PCACHE-102 · Measure saved origin work instead of celebrating the hit ratio
- PCACHE-103 · Create a hot-key workload that exposes synchronized expiry
- PCACHE-104 · Coalesce simultaneous availability misses for one key
- PCACHE-105 · Spread cache refill times without extending the freshness ceiling
- PCACHE-106 · Serve stale availability only within an explicit degraded-read policy
- PCACHE-107 · Prevent a delayed refill from restoring availability older than an update
- PCACHE-108 · Keep origin traffic bounded when the cache becomes unavailable
- PCACHE-109 · Version availability cache payloads without flushing every tenant at once
Acceptance criteria
- Run three paired repetitions of cold, warm, synchronized-expiry and cache-outage phases on the declared workload.
- For the warm phase require at least 60% fewer origin calls than uncached reads, no cross-tenant result and no response beyond the hard freshness limit.
- Require bounded origin concurrency in every phase and publish p95/p99, rejection and stale-response rates; mark invalid or noisy runs inconclusive.
Implementation constraints
- The avoided-call threshold is an exercise budget for the seeded hot-key distribution. Do not infer a production hit rate or freshness guarantee from it.
Verification to include
- Reconcile all attempted reads with results, cache states and actual origin calls for baseline and candidate.
- Revert the chosen configuration and repeat the outage/recovery phase, checking correctness and bounded work after rollback.
Deliverables
- Cache-policy decision, raw measurements and recovery handoff
Rollout and recovery
Promote only the policy satisfying correctness and degraded-mode gates; rollback uses the documented namespace and bounded origin policy.
Value of the work
For the engineer: Learn to evaluate caching through avoided work, bounded staleness, concurrency and recovery rather than hit rate alone.
For the team: Produce a reviewable cache policy and failure exercise for a read-heavy service with changing business data.
Evidence boundaries
Outcome Evidence: Tests, patches, and runbooks are requested deliverables. They become Outcome Evidence only through a qualified Mission and immutable Evidence IDs.
Ownership Evidence: Independent adaptation must be observed under a declared verification policy and cite immutable Evidence IDs. Completing a planning ticket establishes no Ownership Evidence.