You have a million response times and a colleague asking “is it slow?”
This lab builds the four functions that turn that pile of numbers into an answer. None of them is algorithmically hard. All of them have an edge that people get wrong on the first attempt, and the tests are aimed squarely at those edges.
What to implement
percentile(samples, p) — nearest-rank, not interpolation. Sort ascending,
take the element at index ceil(p / 100 * n) - 1. Watch two things: the default
Array.sort() compares as strings, and the caller’s array is not yours to
reorder.
summarise(samples) — returns { mean, p50, p95, p99, worst, count }. This
is the object a dashboard would render.
shareFasterThanMean(samples) — the fraction of requests strictly faster
than the mean. On a realistic distribution this comes out above 0.9, which is
the whole argument of the lesson expressed as a number.
checkSlo(samples, thresholdMs, target) — returns
{ met, achieved, budgetRemaining }. The error budget is the interesting part:
a 99% target permits 1% of requests to miss the threshold, so if only 0.4%
missed, 60% of the budget is unspent. A team that has overspent has zero
budget left, not a negative amount — and a 100% target permits nothing, which
means the usual division has a zero in the denominator.
Run the tests as you go; the failure messages are written to tell you which edge you are standing on.