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

2 min lesson

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

Take "Task 3 - dedup retries into logical attempts before a failure rate" step by step, then finish with the result that proves it worked.

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 + 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, not rows. Failure rate = failed logical attempts / total logical attempts.
  4. 4Sanity-check the denominator. Confirm attempt count is below row count by roughly your retry rate; if they're equal, your dedup didn't fire.
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;
Interview move

Narrate two sanity checks per query without being asked: one on the denominator (does N look right for the window) and one on a known-good slice (does the newest client_version show fewer timeouts than last month). The screener is grading whether you trust-but-verify your own numbers. 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?