# noCV engineering task library Content version 5 Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Tests, patches, and runbooks are requested deliverables. They become Outcome Evidence only through a qualified Mission and immutable Evidence IDs. Independent adaptation must be observed under a declared verification policy and cite immutable Evidence IDs. Completing a planning ticket establishes no Ownership Evidence. ## ACACHE — Keep shared product caches consistent across writers A fictional wholesale portal caches product availability descriptions across several API instances. Delayed invalidations and slow refreshes bring back old content after edits. **Field:** Distributed systems. **Suggested stack:** TypeScript, PostgreSQL, Redis. **Engineer value:** Practice cache consistency, version guards and recoverable invalidation. **Company value:** Review fast derived reads without losing authoritative state or tenant isolation. **Delivery agreement:** Ten scoped tickets across three phases. Build a synthetic local service or select a ticket after recreating its prerequisites; estimates exclude setup. ### Setup prerequisites - Create two local cache clients and a synthetic authoritative product store. - Use a fake clock and controllable read/write barriers. ### Define cache meaning Bind keys, versions and freshness to authoritative data. #### ACACHE-101 — Define cache keys from every product-view authority input **Task · High priority · Foundational** noCV practice brief v5 · ACACHE-101 · Keep shared product caches consistent across writers Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define cache meaning. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 50% · Security 50%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. Two customer organizations request the same SKU but have different visible product descriptions, and the shared cache returns the first result. 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 - 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. Project prerequisites: Create two local cache clients and a synthetic authoritative product store. Use a fake clock and controllable read/write barriers. Engineer value: Practice cache consistency, version guards and recoverable invalidation. Company value: Review fast derived reads without losing authoritative state or tenant isolation. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. #### ACACHE-102 — Specify what stale product data the portal may display **Task · Medium priority · Intermediate** noCV practice brief v5 · ACACHE-102 · Keep shared product caches consistent across writers Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define cache meaning. Depends on: ACACHE-101. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 60% · System design 40%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. The cache uses one TTL for descriptive text and order-critical availability, though they have different correctness needs. Acceptance criteria - Classify fields by tolerated staleness. - Keep authoritative order decisions outside stale display data. - Define fresh, stale-allowed and unusable cache states. Implementation constraints - Use explicit hypothetical freshness bounds with product approval noted as pending. Verification - Serve stale descriptive text within the declared window. - Reject using stale cached availability to authorize an order. Deliverables - Cache consistency matrix Rollout and recovery: Review the matrix before changing TTLs; leave unresolved critical reads authoritative. Project prerequisites: Create two local cache clients and a synthetic authoritative product store. Use a fake clock and controllable read/write barriers. Engineer value: Practice cache consistency, version guards and recoverable invalidation. Company value: Review fast derived reads without losing authoritative state or tenant isolation. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. #### ACACHE-103 — Record authoritative product revision with each cached projection **Task · Medium priority · Foundational** noCV practice brief v5 · ACACHE-103 · Keep shared product caches consistent across writers Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define cache meaning. Depends on: ACACHE-101, ACACHE-102. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 80% · API design 20%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. An API instance receives two cached values but cannot tell which reflects the newer database update. Acceptance criteria - Store source revision and projection version with the value. - Reject malformed or unknown envelopes. - Keep fetch time separate from source revision. Implementation constraints - Do not use cache write time as data ordering authority. Verification - Compare cached revisions 7 and 8. - Read an envelope missing revision and treat it as unusable. Deliverables - Versioned cache envelope Rollout and recovery: Deploy readers that accept the envelope before enabling new writers; miss safely on legacy values. Project prerequisites: Create two local cache clients and a synthetic authoritative product store. Use a fake clock and controllable read/write barriers. Engineer value: Practice cache consistency, version guards and recoverable invalidation. Company value: Review fast derived reads without losing authoritative state or tenant isolation. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. ### Guard shared refreshes Order writes, invalidations and concurrent fills. #### ACACHE-104 — Commit product changes with a durable invalidation fact **Story · High priority · Advanced** noCV practice brief v5 · ACACHE-104 · Keep shared product caches consistent across writers Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Guard shared refreshes. Depends on: ACACHE-101, ACACHE-103. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 60% · Database engineering 40%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. The product write commits and then the process dies before deleting shared cache keys. Acceptance criteria - Persist the product revision and invalidation outbox fact atomically. - Bind invalidation identity to product scope and revision. - Replay invalidation safely after a crash. Implementation constraints - Cache failure must not roll back an already committed product change. Verification - Crash after database commit and dispatch the retained invalidation. - Replay the same invalidation and retain correct cache state. Deliverables - Product/outbox transaction and recovery test Rollout and recovery: Canary one synthetic product class; monitor pending invalidations and fall back to authoritative reads when stale bounds expire. Project prerequisites: Create two local cache clients and a synthetic authoritative product store. Use a fake clock and controllable read/write barriers. Engineer value: Practice cache consistency, version guards and recoverable invalidation. Company value: Review fast derived reads without losing authoritative state or tenant isolation. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. #### ACACHE-105 — Prevent a slow cache fill from overwriting a newer product revision **Bug · High priority · Expert** noCV practice brief v5 · ACACHE-105 · Keep shared product caches consistent across writers Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Guard shared refreshes. Depends on: ACACHE-103, ACACHE-104. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 80% · Database engineering 20%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. A read for revision 7 starts before an edit, then finishes after revision 8 has already been cached and overwrites it. Acceptance criteria - Use an atomic revision comparison when publishing a fill. - Reject lower source revisions regardless of completion order. - Keep projection-version incompatibility separate from source ordering. Implementation constraints - Implement with a bounded Redis script or provider-level compare-and-set. Verification - Pause an old fill, publish the new revision, then resume the old fill. - Attempt a malformed revision and verify it cannot replace the current value. Deliverables - Version-guarded fill and race reproduction Rollout and recovery: Canary guarded fills; disable cache publication if the adapter lacks atomic comparison. Project prerequisites: Create two local cache clients and a synthetic authoritative product store. Use a fake clock and controllable read/write barriers. Engineer value: Practice cache consistency, version guards and recoverable invalidation. Company value: Review fast derived reads without losing authoritative state or tenant isolation. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. #### ACACHE-106 — Handle delayed invalidation without evicting a newer cache revision unnecessarily **Task · Medium priority · Advanced** noCV practice brief v5 · ACACHE-106 · Keep shared product caches consistent across writers Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Guard shared refreshes. Depends on: ACACHE-104, ACACHE-105. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 100%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. An old invalidation arrives after a fresh fill and deletes valid data, triggering avoidable refresh work across instances. Acceptance criteria - Compare invalidation revision with cached source revision. - Evict or mark stale only entries covered by the event. - Treat missing or incompatible envelopes as safe misses. Implementation constraints - Keep invalidation decisions atomic with cache state inspection. Verification - Deliver revision 7 invalidation against cached revision 8 and retain it. - Deliver matching/newer invalidation and enforce the declared stale behavior. Deliverables - Revision-aware invalidation and ordering tests Rollout and recovery: Enable after envelope rollout; fall back to conservative eviction on unknown formats. Project prerequisites: Create two local cache clients and a synthetic authoritative product store. Use a fake clock and controllable read/write barriers. Engineer value: Practice cache consistency, version guards and recoverable invalidation. Company value: Review fast derived reads without losing authoritative state or tenant isolation. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. #### ACACHE-107 — Bound duplicate refresh work across API instances **Story · Medium priority · Intermediate** noCV practice brief v5 · ACACHE-107 · Keep shared product caches consistent across writers Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Guard shared refreshes. Depends on: ACACHE-102, ACACHE-105, ACACHE-106. Difficulty: Intermediate. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 60% · Performance engineering 40%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. A popular product expires and every API instance refreshes it simultaneously, increasing pressure on the source database. Acceptance criteria - Use a bounded per-key refresh ownership mechanism. - Waiters have a deadline and declared stale/miss fallback. - Expired refresh ownership cannot publish an older revision. Implementation constraints - A refresh lock reduces duplicate work; revision fencing still protects correctness. Verification - Request one expired synthetic key from two clients and observe bounded refresh calls. - Pause the owner past expiry and verify stale completion cannot overwrite newer data. Deliverables - Shared refresh coordinator and expired-owner test Rollout and recovery: Canary a small key cohort; disable coordination while retaining revision guards if locks stall. Project prerequisites: Create two local cache clients and a synthetic authoritative product store. Use a fake clock and controllable read/write barriers. Engineer value: Practice cache consistency, version guards and recoverable invalidation. Company value: Review fast derived reads without losing authoritative state or tenant isolation. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. ### Recover cache uncertainty Handle outages, reconcile generations and expose staleness. #### ACACHE-108 — Fall back predictably when the shared cache is unavailable **Task · Medium priority · Advanced** noCV practice brief v5 · ACACHE-108 · Keep shared product caches consistent across writers Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover cache uncertainty. Depends on: ACACHE-102, ACACHE-104, ACACHE-107. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 40% · Site reliability 30% · Performance engineering 30%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. A Redis outage makes every request retry repeatedly, overwhelming the authoritative database while users wait. Acceptance criteria - Bound cache attempts and stop retry amplification. - Apply an explicit source-read admission limit. - Return the declared degraded or unavailable response when both paths lack capacity. Implementation constraints - Use local adapter failures and synthetic requests. Verification - Disconnect the cache and serve an admitted authoritative read. - Exceed fallback admission and return a bounded failure without unbounded source calls. Deliverables - Cache-outage fallback and overload probe Rollout and recovery: Canary with conservative fallback limits; shed excess reads until cache recovery is verified. Project prerequisites: Create two local cache clients and a synthetic authoritative product store. Use a fake clock and controllable read/write barriers. Engineer value: Practice cache consistency, version guards and recoverable invalidation. Company value: Review fast derived reads without losing authoritative state or tenant isolation. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. #### ACACHE-109 — Reconcile cache generations after a projection-schema release **Chore · Medium priority · Expert** noCV practice brief v5 · ACACHE-109 · Keep shared product caches consistent across writers Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover cache uncertainty. Depends on: ACACHE-103, ACACHE-105, ACACHE-108. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 70% · Platform engineering 30%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. A new release changes product projection shape while old and new API instances share cached envelopes. Acceptance criteria - Use explicit projection namespaces and compatible-reader declarations. - Warm a new namespace from authoritative revisions. - Retire the old namespace only after old readers are gone. Implementation constraints - Do not rewrite old cache values into a guessed new schema. Verification - Run mixed-version clients against their declared namespaces. - Send a new envelope to an incompatible reader and verify safe miss or rejection. Deliverables - Cache-generation rollout and compatibility drill Rollout and recovery: Switch one synthetic cohort first; restore its previous namespace while keeping authoritative data unchanged. Project prerequisites: Create two local cache clients and a synthetic authoritative product store. Use a fake clock and controllable read/write barriers. Engineer value: Practice cache consistency, version guards and recoverable invalidation. Company value: Review fast derived reads without losing authoritative state or tenant isolation. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. #### ACACHE-110 — Expose cache freshness observations without claiming source correctness **Task · Medium priority · Foundational** noCV practice brief v5 · ACACHE-110 · Keep shared product caches consistent across writers Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover cache uncertainty. Depends on: ACACHE-102, ACACHE-108, ACACHE-109. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 50% · Site reliability 50%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. The dashboard shows a high hit rate as proof the product data is correct, though hit count says nothing about revision freshness. Acceptance criteria - Report hit/miss, source revision and observed freshness separately. - Mark unknown source comparison explicitly. - Avoid exposing product payloads in generic telemetry. Implementation constraints - Metrics describe cache behavior, not business-data correctness. Verification - Observe a fresh hit with a known source revision. - Hide source revision availability and report unknown freshness despite a cache hit. Deliverables - Cache health projection and semantics notes Rollout and recovery: Add freshness diagnostics before tuning hit-rate targets; retain unknown states during outages. Project prerequisites: Create two local cache clients and a synthetic authoritative product store. Use a fake clock and controllable read/write barriers. Engineer value: Practice cache consistency, version guards and recoverable invalidation. Company value: Review fast derived reads without losing authoritative state or tenant isolation. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence.