Service Level Indicators

What Makes a Good SLI

 an SLI is a RATIO, carefully framed:

   good events / valid events

 the denominators matter as much as numerators:

 ✗ "successful requests / ALL requests including healthchecks"
     → monitoring pings inflate your numbers into fiction

 ✓ "requests serving correct results within latency bound /
    requests from real user traffic"

 specification checklist:
 □ which REQUESTS count (exclude synthetic/health/internal?)
 □ what counts as GOOD (status? correctness? latency bound?)
 □ measured WHERE (server-side? client-side? both tell truths)

The Standard SLI Set

SLI	Definition	Captures
Availability	non-error responses / total	is it working at all
Latency	responses < threshold / total	is it fast enough
Freshness	reads within staleness bound / total	is data current
Correctness	verified-right answers / sampled	does it lie
Throughput	handled / offered (per capacity)	saturation behavior

 latency SLI nuance: use PERCENTILE-of-requests framing,
 not averages: "99% of requests < 400ms".
 averages hide the tail where humans live.

Client-Side vs Server-Side

 SERVER-side (easy, standard):
   you see requests that REACHED you.
   blind to: DNS failures, network blackholes, CDN issues,
   client-side rendering disasters.

 CLIENT-side (RUM — real user monitoring):
   measures the ACTUAL experienced thing:
   tap-to-render, full load, error surfaces.
   harder to instrument; closer to truth.

 mature systems run BOTH:
 server SLIs for engineering SLOs;
 client metrics to catch everything between you and the eyeball.
 divergence between them = network/edge incident signal.

Instrumentation Mechanics

 □ COUNT at the edge of responsibility: LB or ingress for
   request-level truth; deep internals for diagnosis only
 □ LABEL sparsely: by endpoint-class and region —
   high-cardinality labels destroy metric storage
 □ WINDOW honestly: 28-day compliance windows are standard;
   also expose 1h rolling for operational sanity
 □ DEFINE in code/config as spec, not wiki prose —
   the alerting queries read THE definition. one source.

Interview Framing

“What would you measure for this chat system?” scored answer: pick 3–4 concrete SLIs with ratio definitions (“messages delivered end-to-end <2s / messages sent”, excluding reconnect storms), client+server split mentioned, percentile framing used instinctively. The denominator-exclusion reasoning (healthcheck pollution) is the subtle test most candidates fail.