Another source of complexity can arise from choosing different thresholds for each of your latency, freshness, or throughput SLOs. Just as you tend to choose from the set of round nines, like three nines or four nines when setting SLO targets, it's a good idea to have small set of known good thresholds with easily recognizable labels that are used across all your SLOs. This can make them easy to reason about, and compare directly. In our experience, you probably won't need more than three to five thresholds for latency, because you can break down your users request response interactions into a few discrete buckets. The easiest distinction to make between classes of requests is whether a user is actively awaiting the response. Some requests may be made in the background, for example by a mobile client to cache data overnight while on WI-FI and AC power. Others may be made by non-human users like Googlebot. If you can accurately identify these requests and you're sure the overall user experience is not going to be negatively impacted by serving them more slowly, then you might choose to put them in a bucket with a very loose background latency threshold, which is doing little more than ensuring long tail latency for these requests is still reasonable. For the remainder of your request where you're pretty sure a user is waiting for a response, the next bucket you might create is for write requests that mutate state in your service. In our experience, writes in distributed systems, especially consistent writes, have significantly different latency characteristics to reads. Fortunately, because of this, users tend to be accustomed to and more accepting of slower responses when they have clicked the submit button, so a different threshold for these requests is reasonable. This leaves read-only interactive request, which you probably want to respond to quickly. This bucket tends to have the strictest latency thresholds. These three buckets, interactive, write, and background are usually enough to cover most simple latency SLIs. In the previous lesson, we suggested you might want to have more than one latency threshold to measure different parts of the latency distribution. At Google, we tend to call the threshold for measuring broad based latency, usually associated with slow target of 50-75% of requests being faster than this threshold, annoying requests. And then, we call the long tail threshold where latency is greater than 90% of requests painful requests. Services measuring two points on the distribution then end up with buckets for annoying interactive and painful interactive requests for example. One last bucket you may need to consider is for request that have a dependency outside your control like a payment processor or identity provider. You can't magically make these things go faster, no matter how much you might want to. Your users may not be happy about the performance of these things, but if they are understanding and don't hold you directly responsible, then it's acceptable to set achievable latency thresholds for these requests rather than the ones you don't have a hope of meeting. We've covered many ideas to think about when choosing a good SLI. In the next lesson, we're going to talk about setting and iterating on SLO targets.
