Proposing availability and latency SLIs for an auth API

WHAT THIS TESTS This probes whether you can define SLIs that are measurable, resistant to gaming, and faithful to the actual user experience for a specific, critical service.

A GOOD ANSWER COVERS For availability, propose the ratio of successful authentication requests to total valid authentication requests, where success means a correct response without server-side failure. Count 5xx responses and timeouts as failures, but exclude legitimate client errors like a 401 for a genuinely wrong password, since those represent the system working correctly, not an outage. For latency, propose the proportion of authentication requests completed under a target threshold, such as the fraction served in under three hundred milliseconds, framed as a percentage of fast requests rather than a single average. Justify both by where they are measured: capture them as close to the user as possible, ideally at the load balancer or client, because that is what the user actually feels, not internal server timing that omits queueing and network.

COMMON WRONG ANSWERS Counting all non-200 responses, including valid 401 and 400 client errors, against availability, which punishes correct behavior. Reporting latency only as a mean, which hides the slow tail that frustrates real users. Measuring deep inside the service so the SLI ignores the queueing and edge latency the user experiences.

LIKELY FOLLOW-UPS What threshold and window would you pick? Why percentiles over averages? How would you handle a flood of invalid requests skewing the ratio? How do these SLIs feed an SLO and error budget?

ONE CONCRETE EXAMPLE Define availability as the count of authentication responses that are not 5xx divided by the count of all valid authentication requests, measured at the API gateway, targeting 99.95 percent over twenty-eight days. Define latency as the proportion of those requests with end-to-end duration under three hundred milliseconds, also at the gateway, targeting 99 percent. If a downstream token store slows down, the latency SLI degrades visibly even while availability holds, giving an early, user-centric signal that something is wrong before logins start outright failing.