Capstone — Probability & Statistics in Practice

Two problem types are logged per session: A = "UI error" (P(A) = 0.03) and B = "timeout" (P(B) = 0.02), with P(A ∩ B) = 0.005 — some sessions hit both. The union rule gives the overall "any problem" rate: P(A ∪ B) = 0.03 + 0.02 − 0.005 = 0.045. The complement rule then gives the genuinely useful number: P(clean session) = 1 − 0.045 = 0.955 — 95.5% of sessions have no problem at all.

Testing independence: P(A) × P(B) = 0.03 × 0.02 = 0.0006, but the actual P(A ∩ B) = 0.005 — over eight times larger. They are clearly not independent. Computing P(timeout | UI error) = 0.005 / 0.03 ≈ 16.7% — far above the 2% baseline timeout rate — confirms the two problems cluster together, consistent with a shared root cause like server overload rather than two unrelated glitches.

A monitoring alert fires when the problem rate spikes. Genuine load issues happen on 5% of days (P(load) = 0.05); the alert catches 90% of real load issues (P(alert|load) = 0.9) but also false-fires on 3% of normal days (P(alert|no load) = 0.03). By the law of total probability, P(alert) = (0.9)(0.05) + (0.03)(0.95) = 0.0735. Bayes' Theorem then gives P(load | alert) = 0.045 / 0.0735 ≈ 61.2% — a meaningfully informative alert, though still short of certainty, exactly the base-rate reasoning Chapter 4 built.

The rollout's cost, as a random variable: P(no rollback) = 0.85 (cost $0), P(partial rollback) = 0.12 (cost $3,000), P(full rollback) = 0.03 (cost $40,000). Expected value: E[X] = 0(0.85) + 3,000(0.12) + 40,000(0.03) = 360 + 1,200 = $1,560 — the number the team should actually budget for, not the (much lower) most-likely single outcome.

Reusing Chapter 6's own conversion rate, p = 0.2, for n = 10 canary users: what's the probability at least half convert (X ≥ 5)? Summing the binomial PMF from k = 5 to 10 gives P(X ≥ 5) ≈ 0.033 (3.3%). If the canary group actually shows 5 or more conversions, that's a genuinely rare result under the existing 20% rate — real evidence the new feature may be improving conversion, not just random noise.

Reusing Chapter 7's own incident rate, λ = 3 per week: what's the probability of at least 2 incidents during the rollout's first monitored week? P(X ≥ 2) = 1 − P(X=0) − P(X=1) = 1 − 0.0498 − 0.1494 ≈ 0.801 (80.1%) — a week with two or more incidents is actually the normal case at this rate, not a red flag on its own.

Reusing Chapter 8's own response-time model, μ = 200ms, σ = 30ms: the probability a request falls between 170ms and 230ms (within 1σ either side) is P(170 < X < 230) ≈ 0.6827 — matching the empirical rule's 68% directly. For a monitoring dashboard averaging 100 requests at a time, the Central Limit Theorem gives that average's own standard error: SE = 30/√100 = 3ms — the averaged metric is far more stable than any single request's own time, exactly why dashboards average in the first place.

Reusing Chapter 9's own seven sampled response times — 120, 115, 130, 125, 118, 122, 890 — one request during the rollout was genuinely slow. Mean: 231.43ms. Median: 122ms. Reporting "average response time: 231ms" to stakeholders would badly misrepresent what most users actually experienced — the median, far less shaken by the single outlier, is the honest number to lead with.