Skip to main content

Review case packet: cached reservation reads

This is a fictional teaching packet, not measured performance from the author's project. Attempt the review before opening calibration. The numbers are deliberately incomplete evidence.

Brief and constraints​

A two-tenant reservation service proposes a read cache. The accepted scenario requires 95% of eligible read attempts to succeed within 120 ms under an agreed workload. A completed authorization change must prevent subsequent reads by the revoked principal. A deletion completion acknowledgment promises that subsequent reads will not return that record. Writes already have an idempotency policy, but its restart and expiry tests are missing.

Options are direct reads with query/index tuning, an application cache, and a read replica with session routing. Each must be evaluated against the same latency, authorization, deletion, freshness, recovery and operating-cost scenarios. No option is automatically correct.

Submitted evidence​

  • E1: direct-read sample has 100 eligible attempts, 90 successful within 120 ms, 8 slow successes and 2 failures.
  • E2: warm-cache export contains 100 successful completed reads, 98 within 120 ms. A separate client dispatch ledger lists 110 attempts; no terminal records are supplied for the other 10.
  • E3: a screenshot shows the cache returning a revoked user's previously readable record after authorization-change completion. The cache key is record ID only. Tenant filtering is applied after cache retrieval; the reviewer must determine which content can escape and where authorization is enforced.
  • E4: deletion test removes the database row and confirms direct reads fail, but it never reads through a previously warmed cache after the completion acknowledgment.
  • E5: two sequential requests with one retry key create one reservation. There are no concurrent, restart, payload-conflict or expiry traces.
  • E6: the proposed ADR says “cache reduces latency and is safe; all risks closed.” Its only linked source is E2. It omits operating effort and rollback behavior.

Tasks and submission​

  1. Classify each material statement as observation, inference, assumption or unsupported claim. Calculate only metrics justified by the population and records provided.
  2. Write three blocking findings tied to integrity/evidence requirements and one nonblocking question. Name what would close each; avoid prescribing a tool without identifying its mechanism.
  3. Draft an ADR with all three options and a provisional decision. An explicit “defer cache acceptance pending evidence; retain baseline temporarily with known latency gap” is allowed, but is not completion of the target scenario.
  4. Design the smallest experiment that discriminates the viable options under cold/warm load, revoked access and deletion. Freeze the criteria before running it.
  5. Conduct a 60-minute review: 10 framing, 20 scenarios/evidence, 15 risks/options, 10 decision and owners, 5 read-back of unresolved work. A solo role-play is practice; label it and arrange an independent review for completion.
  6. Submit a findings register, revised decision, evidence plan and a reopening trigger. Then use the original project to execute one closure test and one deliberately failing fitness check.

Change card — reveal after the initial decision​

The client team needs to roll back to an older release during rollout. Its requests omit a newly added field, and its response decoder rejects unknown fields. The cache team also changes serialization libraries. Identify which compatibility, cache-content and rollback claims must be revalidated; do not reopen unrelated domain facts without a reason.

The assessment and calibration distinguishes a defensible provisional choice from unearned acceptance. Preserve first drafts and review disagreements.