Skip to lesson
Exit
Capstone: Mock Loop & Self-Exam1 / 2

2 min lesson

Task 3: dedup retries into logical attempts before a failure rate

Start at the first move in "Task 3: dedup retries into logical attempts before a failure rate" and carry it through to the proof.

Step 1 of 2

Task 3: dedup retries into logical attempts before a failure rate

A flaky network produces three rows for one user intent: two timeouts then an ok. Counting raw rows reports a 67% failure rate for something the user experienced as a success. Roll up to the logical attempt first.

  1. 1Define the logical attempt. Group retries under one key: request_id, or a window of user_id plus the same prompt within N seconds if no request_id exists.
  2. 2Collapse status with a precedence rule. A logical attempt succeeds if any of its tries succeeded; it fails only if every try failed. Decide and state the rule.
  3. 3Compute the rate on attempts. Failure rate = failed logical attempts / total logical attempts.
  4. 4Sanity-check the denominator. Same check as the gate in the run above.
retry-aware failure rate: succeed if any try succeeded
WITH attempt AS (
  SELECT
    request_id,
    BOOL_OR(status = 'ok')                              AS any_ok,
    COUNT(*)                                            AS tries
  FROM interaction_events
  WHERE event_type IN ('success', 'error', 'timeout')
  GROUP BY request_id
)
SELECT
  COUNT(*)                                              AS logical_attempts,
  COUNT(*) FILTER (WHERE NOT any_ok)                     AS failed_attempts,
  ROUND(100.0 * COUNT(*) FILTER (WHERE NOT any_ok)
              / COUNT(*), 2)                             AS failure_rate_pct,
  ROUND(AVG(tries), 2)                                  AS avg_tries
FROM attempt;
Say it like this: two sanity checks

"Denominator check: 18k attempts from 22k rows means about 18% of rows were retries, which matches the retry rate I expect, so the dedup fired. Known-slice check: the newest client_version shows fewer timeouts than last month, as it should. Both hold, so I'll quote the number."

The 18k, 22k and 18% are example values; use your own. Silent correctness reads as luck, narrated correctness reads as rigor.

Learn more

Full explanation

Self-score the run

Self-score the run

Axis
Correctness
Weak (1-2)
Averaged latency; counted raw rows as failures.
Strong (4-5)
Percentiles, attempt-level dedup, correct denominators.
Axis
Rigor
Weak (1-2)
Returned a number with no checks.
Strong (4-5)
Stated assumptions; ran a denominator and a known-slice check.
Axis
Communication
Weak (1-2)
Typed in silence.
Strong (4-5)
Narrated each metric definition and why before running it.
Axis
Speed
Weak (1-2)
Stuck on syntax; ran out of clock.
Strong (4-5)
Reached three working answers inside the hour with time to sanity-check.

Anything you score 3 or below is a rep to repeat before the real screen.

QYour raw events table shows a 9% timeout rate. After grouping by request_id and treating an attempt as successful if any try succeeded, it drops to 3%. Which number do you report as the reliability metric and why?