Specify which availability responses may be reused
Two requests for the same product receive different answers because depot and tenant affect availability. The prototype cache key contains only the product ID.
- Focused work estimate
- 1h 15m + prerequisites
- Priority in the scenario
- High
- Engineering practice
- Cache semantics · Tenant isolation
Estimated field mix
- API design40%
- Security30%
- Performance engineering30%
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
No earlier ticket is required. Complete the project setup above.
Acceptance criteria
- Include tenant, depot, product and response-schema version in an unambiguous cache-key contract.
- State the maximum informational freshness window and keep booking decisions on the authoritative origin.
- Define which errors and absence responses are cacheable, with a separate bounded lifetime where appropriate.
Implementation constraints
- Use opaque synthetic identifiers and avoid leaking sensitive request values through diagnostic key labels.
Verification to include
- Request the same product from two depots and tenants and verify no shared response.
- Construct delimiter-collision inputs and confirm distinct semantic keys remain distinct.
Deliverables
- Cache-key and freshness contract with boundary fixtures
Rollout and recovery
Introduce a new key namespace for the contract; expiry cleans old derived entries without rewriting authoritative availability.
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.