noCV
ACACHE-101 · Define cache meaning

Define cache keys from every product-view authority input

Practice briefTaskFoundational

Two customer organizations request the same SKU but have different visible product descriptions, and the shared cache returns the first result.

Focused work estimate
1h 30m + prerequisites
Priority in the scenario
High
Engineering practice
Cache identity · Tenant isolation

Estimated field mix

  • Distributed systems50%
  • Security50%

Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence.

Your next step

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 wholesale portal caches product availability descriptions across several API instances. Delayed invalidations and slow refreshes bring back old content after edits.

Setup prerequisites

  • Create two local cache clients and a synthetic authoritative product store.
  • Use a fake clock and controllable read/write barriers.

Preceding work

No earlier ticket is required. Complete the project setup above.

Acceptance criteria

  • Bind keys to organization, view policy and product identity.
  • Authorize before cache lookup.
  • Version the key namespace for incompatible projection changes.

Implementation constraints

  • Do not include secrets or raw personal data in keys.

Verification to include

  • Cache different permitted views of the same synthetic SKU.
  • Request another organization's view and verify no cross-scope hit.

Deliverables

  • Canonical cache-key contract

Rollout and recovery

Introduce a fresh namespace and expire the affected old namespace.

Value of the work

For the engineer: Practice cache consistency, version guards and recoverable invalidation.

For the team: Review fast derived reads without losing authoritative state or tenant isolation.

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.