Serve stale availability only within an explicit degraded-read policy

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

Acceptance criteria

• Define fresh, stale-but-allowed and expired states with explicit age limits and response metadata.
• Choose bounded background refresh behavior and retain authoritative booking checks.
• After the hard age limit, return an explicit unavailable outcome rather than an apparently current availability summary.

Implementation constraints

• The policy concerns informational reads only. Preserve origin-error visibility and do not cache authorization failures as product absence.

Verification to include

• Advance the clock across both boundaries during origin success and failure, checking age metadata and result state.
• Run concurrent stale reads with a blocked refresh and verify bounded origin work and transition to unavailable after the hard limit.

Deliverables

• Freshness state machine, degraded-read implementation and boundary matrix

Rollout and recovery

Canary with response-age and stale-outcome counters; disable stale serving immediately if clients fail to present the declared state.

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.