# 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. ## PCACHE — Keep product availability caching correct during a traffic spike 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. **Field:** Performance engineering. **Suggested stack:** TypeScript, Redis, HTTP, k6. **Engineer value:** Learn to evaluate caching through avoided work, bounded staleness, concurrency and recovery rather than hit rate alone. **Company value:** Produce a reviewable cache policy and failure exercise for a read-heavy service with changing business data. **Delivery agreement:** Ten tickets in three phases. Availability is informational; booking remains an authoritative origin operation. All load and failure experiments use owned local services. ### 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. ### Define cache meaning and baseline Specify keys, freshness and measurements before optimization. #### PCACHE-101 — Specify which availability responses may be reused **Task · High priority · Foundational** noCV practice brief v5 · PCACHE-101 · Keep product availability caching correct during a traffic spike Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define cache meaning and baseline. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 75 minutes; setup and prerequisite tickets are additional. Estimated field mix: API design 40% · Security 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. Two requests for the same product receive different answers because depot and tenant affect availability. The prototype cache key contains only the product ID. 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 - 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. Project 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. Engineer value: Learn to evaluate caching through avoided work, bounded staleness, concurrency and recovery rather than hit rate alone. Company value: Produce a reviewable cache policy and failure exercise for a read-heavy service with changing business data. 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. #### PCACHE-102 — Measure saved origin work instead of celebrating the hit ratio **Task · Medium priority · Foundational** noCV practice brief v5 · PCACHE-102 · Keep product availability caching correct during a traffic spike Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define cache meaning and baseline. Depends on: PCACHE-101. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Performance engineering 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. The cache reports a high hit ratio, but every hit still triggers a synchronous origin validation and costs almost as much as a miss. Acceptance criteria - Record hits, misses, stale responses, origin calls, origin work duration and end-to-end request latency separately. - Use bounded labels and report the same workload window and request counts for all rates. - Define avoided origin calls against an uncached run of the identical seeded requests. Implementation constraints - Do not combine cache and origin error outcomes into successful hits; expose failures and retries explicitly. Verification - Replay a repeated-key fixture and reconcile request count with cache outcomes and actual stub calls. - Enable synchronous validation deliberately and verify the report reveals that high hit rate did not remove origin work. Deliverables - Cache effectiveness report and aggregate counters Rollout and recovery: Run counters beside the existing local behavior before policy changes; preserve raw attempt counts for comparisons. Project 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. Engineer value: Learn to evaluate caching through avoided work, bounded staleness, concurrency and recovery rather than hit rate alone. Company value: Produce a reviewable cache policy and failure exercise for a read-heavy service with changing business data. 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. #### PCACHE-103 — Create a hot-key workload that exposes synchronized expiry **Chore · Medium priority · Intermediate** noCV practice brief v5 · PCACHE-103 · Keep product availability caching correct during a traffic spike Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define cache meaning and baseline. Depends on: PCACHE-101, PCACHE-102. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Performance engineering 80% · Quality 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. Uniform random keys miss often but never reproduce the traffic surge that arrives when the most popular products expire together. Acceptance criteria - Generate a seeded workload where 80% of reads target 20 hot product/depot keys and the remainder sample a larger declared set. - Include a synchronized-expiry phase, a cold start and a quiet recovery period. - Record scheduled and achieved arrivals, timeouts and origin concurrency so generator saturation is visible. Implementation constraints - Use a controllable clock for unit-level expiry cases and a documented arrival schedule for load runs. Verification - Repeat the seed and compare key frequencies and expiry schedule. - Run the uncached and cached paths against the same origin-delay fixture and retain all outcome counts. Deliverables - Hot-key generator and baseline workload manifest Rollout and recovery: Version the workload independently of cache implementation; changing the distribution starts a new comparison baseline. Project 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. Engineer value: Learn to evaluate caching through avoided work, bounded staleness, concurrency and recovery rather than hit rate alone. Company value: Produce a reviewable cache policy and failure exercise for a read-heavy service with changing business data. 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. ### Bound cache work and staleness Handle simultaneous misses, updates and failure without serving another tenant or hiding stale data. #### PCACHE-104 — Coalesce simultaneous availability misses for one key **Story · High priority · Advanced** noCV practice brief v5 · PCACHE-104 · Keep product availability caching correct during a traffic spike Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Bound cache work and staleness. Depends on: PCACHE-101, PCACHE-103. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Performance engineering 60% · Backend 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. Hundreds of requests miss the same just-expired key and each starts an identical origin read. Acceptance criteria - Share one bounded in-flight fill per semantic key within the declared process scope. - Give each waiter its own deadline and release the in-flight entry on success, failure and cancellation. - Keep different tenants and keys independent, and document that process-local coalescing does not coordinate multiple instances. Implementation constraints - Use a deterministic origin latch to prove fan-in; a fast origin can hide duplicate concurrent fills in a timing-only test. Verification - Release 100 simultaneous same-key reads and verify one origin fill with identical successful results. - Cancel some waiters and fail the fill; verify remaining outcomes, cleanup and a successful subsequent retry. Deliverables - Single-flight implementation and concurrency/failure regressions Rollout and recovery: Gate coalescing locally; disabling it preserves the same freshness contract and drains existing waiters before removing entries. Project 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. Engineer value: Learn to evaluate caching through avoided work, bounded staleness, concurrency and recovery rather than hit rate alone. Company value: Produce a reviewable cache policy and failure exercise for a read-heavy service with changing business data. 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. #### PCACHE-105 — Spread cache refill times without extending the freshness ceiling **Story · Medium priority · Intermediate** noCV practice brief v5 · PCACHE-105 · Keep product availability caching correct during a traffic spike Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Bound cache work and staleness. Depends on: PCACHE-101, PCACHE-103. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Performance engineering 80% · Backend 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 bulk warmup writes every popular key with the same lifetime. They expire in one wave and overload the origin. 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 - 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. Project 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. Engineer value: Learn to evaluate caching through avoided work, bounded staleness, concurrency and recovery rather than hit rate alone. Company value: Produce a reviewable cache policy and failure exercise for a read-heavy service with changing business data. 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. #### PCACHE-106 — Serve stale availability only within an explicit degraded-read policy **Story · High priority · Expert** noCV practice brief v5 · PCACHE-106 · Keep product availability caching correct during a traffic spike Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Bound cache work and staleness. Depends on: PCACHE-101, PCACHE-102, PCACHE-104. Difficulty: Expert. Estimated focused work: 330 minutes; setup and prerequisite tickets are additional. Estimated field mix: Site reliability 50% · API design 30% · Performance 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. During a short origin outage the cache can show useful recent information, but the prototype serves old availability indefinitely and presents it as current. 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 - 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. Project 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. Engineer value: Learn to evaluate caching through avoided work, bounded staleness, concurrency and recovery rather than hit rate alone. Company value: Produce a reviewable cache policy and failure exercise for a read-heavy service with changing business data. 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. #### PCACHE-107 — Prevent a delayed refill from restoring availability older than an update **Bug · High priority · Expert** noCV practice brief v5 · PCACHE-107 · Keep product availability caching correct during a traffic spike Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Bound cache work and staleness. Depends on: PCACHE-101, PCACHE-104, PCACHE-106. Difficulty: Expert. Estimated focused work: 330 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. An origin read starts before a stock update, then finishes after invalidation and writes the old value back into the cache. Acceptance criteria - Associate fills and updates with an explicit revision or generation rule. - Reject an obsolete fill after a newer invalidation or value is known within the chosen coordination scope. - Document behavior when invalidation delivery is delayed and preserve the hard freshness ceiling as a backstop. Implementation constraints - Use atomic cache operations where a check-and-set race matters; explain limits across multiple readers rather than claiming perfect global freshness. Verification - Hold an old origin response, apply a newer update, then release it and verify the cached revision does not go backward. - Repeat the sequence with duplicate invalidations and a cache reconnect; verify the declared recovery behavior and age bound. Deliverables - Revision protocol, race regression and coordination-limit note Rollout and recovery: Introduce the revisioned namespace gradually; on uncertainty discard derived cache state and use the bounded origin path. Project 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. Engineer value: Learn to evaluate caching through avoided work, bounded staleness, concurrency and recovery rather than hit rate alone. Company value: Produce a reviewable cache policy and failure exercise for a read-heavy service with changing business data. 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. ### Validate degraded and release behavior Exercise cache loss, policy changes and measurable promotion gates. #### PCACHE-108 — Keep origin traffic bounded when the cache becomes unavailable **Story · High priority · Advanced** noCV practice brief v5 · PCACHE-108 · Keep product availability caching correct during a traffic spike Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Validate degraded and release behavior. Depends on: PCACHE-102, PCACHE-104, PCACHE-106. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Site reliability 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 cache outage redirects the full request rate to the origin. The supposed fallback turns a small infrastructure fault into a wider outage. Acceptance criteria - Set cache-client timeouts and bound origin fallback concurrency and queue length. - Return an explicit overload or unavailable response when the fallback budget is exhausted. - Recover cache use without a synchronized refill storm or continuing to queue expired callers. Implementation constraints - Exercise cache disconnect, slow response and recovery separately; do not rely only on a clean process shutdown. Verification - Run the hot-key load while making cache operations hang and assert bounded connection and origin work counts. - Restore the cache during overload and verify queue drainage, timeout accounting and correct tenant-specific responses. Deliverables - Degraded-cache policy, failure injection and recovery traces Rollout and recovery: Canary the bounded fallback configuration locally; retain a switch that fails informational reads explicitly if fallback threatens the origin budget. Project 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. Engineer value: Learn to evaluate caching through avoided work, bounded staleness, concurrency and recovery rather than hit rate alone. Company value: Produce a reviewable cache policy and failure exercise for a read-heavy service with changing business data. 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. #### PCACHE-109 — Version availability cache payloads without flushing every tenant at once **Chore · Medium priority · Advanced** noCV practice brief v5 · PCACHE-109 · Keep product availability caching correct during a traffic spike Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Validate degraded and release behavior. Depends on: PCACHE-101, PCACHE-105, PCACHE-107. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Platform engineering 40% · API design 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 response-field change makes older cached payloads unreadable. Flushing all keys would force a simultaneous cold start across the service. Acceptance criteria - Write a new payload/key version and reject incompatible old payloads safely. - Define a bounded warming or lazy-fill strategy and retain per-tenant scope. - Make rollback behavior explicit when older readers encounter values written during the new release. Implementation constraints - Treat cache payloads as derived data; do not migrate authoritative stock records as part of this change. Verification - Run old and new readers against mixed-version fixtures and verify the documented compatibility behavior. - Switch versions under the hot-key workload and measure origin refill concurrency without a global flush. Deliverables - Payload-version contract, compatibility tests and rollout procedure Rollout and recovery: Canary a small synthetic tenant set, then expand; rollback restores the prior namespace and lets unused versioned entries expire. Project 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. Engineer value: Learn to evaluate caching through avoided work, bounded staleness, concurrency and recovery rather than hit rate alone. Company value: Produce a reviewable cache policy and failure exercise for a read-heavy service with changing business data. 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. #### PCACHE-110 — Choose the cache policy from freshness, origin load and tail latency together **Task · High priority · Expert** noCV practice brief v5 · PCACHE-110 · Keep product availability caching correct during a traffic spike Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Validate degraded and release behavior. Depends on: PCACHE-104, PCACHE-105, PCACHE-106, PCACHE-107, PCACHE-108, PCACHE-109. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Performance engineering 50% · Site reliability 30% · Quality 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. One policy gives the highest hit rate by serving older data. Another is fresh but overloads the origin at expiry. The team needs a decision tied to the actual contract. Acceptance criteria - Run three paired repetitions of cold, warm, synchronized-expiry and cache-outage phases on the declared workload. - For the warm phase require at least 60% fewer origin calls than uncached reads, no cross-tenant result and no response beyond the hard freshness limit. - Require bounded origin concurrency in every phase and publish p95/p99, rejection and stale-response rates; mark invalid or noisy runs inconclusive. Implementation constraints - The avoided-call threshold is an exercise budget for the seeded hot-key distribution. Do not infer a production hit rate or freshness guarantee from it. Verification - Reconcile all attempted reads with results, cache states and actual origin calls for baseline and candidate. - Revert the chosen configuration and repeat the outage/recovery phase, checking correctness and bounded work after rollback. Deliverables - Cache-policy decision, raw measurements and recovery handoff Rollout and recovery: Promote only the policy satisfying correctness and degraded-mode gates; rollback uses the documented namespace and bounded origin policy. Project 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. Engineer value: Learn to evaluate caching through avoided work, bounded staleness, concurrency and recovery rather than hit rate alone. Company value: Produce a reviewable cache policy and failure exercise for a read-heavy service with changing business data. 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.