Spread cache refill times without extending the freshness ceiling

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

Acceptance criteria

• Apply bounded expiry variation that never exceeds the declared maximum freshness window.
• Make the randomness injectable for repeatable tests and preserve explicit short-lived negative-cache policy.
• Report refill concurrency before and after under the synchronized-expiry fixture.

Implementation constraints

• Define whether jitter shortens lifetime or schedules refresh earlier; do not silently extend a business freshness bound.

Verification to include

• Generate many lifetimes with a fixed seed and verify all are positive and within the contractual ceiling.
• Replay the warmup/expiry workload and compare peak origin concurrency while checking response ages.

Deliverables

• Expiry policy, deterministic boundary tests and refill comparison

Rollout and recovery

Roll out the new expiry policy only for newly written entries; reverting changes future writes while existing entries remain within the original ceiling.

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.