Design SLA Monitoring - System Design | WinJob

Problem Statement: SLAs, SLOs, and Error Budgets

Why SLA monitoring is a first-class platform

Interviewers at Datadog, New Relic, and Dynatrace expect you to separate SLI measurement, SLO policy, error-budget enforcement, and customer-facing SLA reporting—not a single "uptime dashboard."

Depth for this section

Define the contract between product and engineering: SLIs measure reality, SLOs set targets, SLAs are business promises. Error budgets gate releases.

Core mechanisms

SLI pipeline — good/bad events or ratio queries aligned to user-visible journeys (checkout success, API availability, pipeline freshness).
SLO evaluator — rolling windows (30d) plus multi-burn detectors (5m/1h fast, 6h/3d slow) tied to remaining error budget.
Governance — versioned policies, audit trails, tenant RBAC, and canary cohort labels so partial rollouts do not poison global compliance.

Operational invariants

Budget is spendable — when burn exhausts budget, freeze releases or require exception approval; do not silently widen targets.
Alerts page on budget threat, not CPU — tie notifications to slo:error_budget:remaining and burn rates.
Compliance is reproducible — store inputs (query + window + exclusions) so contractual disputes replay identically.

Interview signal

Quantify events/sec per SLI, number of active SLOs, evaluation period, and paging latency (<60s). Mention canary auto-rollback when fast burn exceeds 2% of monthly budget in 15 minutes. Compare managed SLO products vs Prometheus recording rules.

Phase focus (`understanding`)

Section 1 locks understanding decisions for Design SLA Monitoring.

javaOne Dark Pro

1 // Illustrative: multi-window burn gate (conceptual)
2 public final class SloBurnGate {
3   private final double budgetFraction;
4   public boolean page(double burn5m, double burn1h) {
5     return burn5m > 14 * budgetFraction || burn1h > 6 * budgetFraction;
6   }
7 }

pythonOne Dark Pro

1 def should_page(burn_5m: float, burn_1h: float, budget: float) -> bool:
2     return burn_5m > 14 * budget or burn_1h > 6 * budget

typescriptOne Dark Pro

1 export function shouldPage(burn5m: number, burn1h: number, budget: number): boolean {
2   return burn5m > 14 * budget || burn1h > 6 * budget;
3 }

How to open this one

The framing that signals depth on SLA monitoring is the SLI/SLO/error-budget hierarchy: you measure an indicator (success rate, latency), set an objective (99.9%), and the gap to 100% is an error budget you spend deliberately. Lead with multi-window burn-rate alerting — fast burn pages now, slow burn opens a ticket — and the failure story that proves it: a single static threshold either pages on noise or misses a slow leak. That shows you understand SLAs are about budgeting reliability, not chasing 100%.

Key Highlights

•SLIs must reflect user-visible behavior
•Multi-window burn reduces false positives
•Versioned SLO policies enable audit replay
•Canary cohort labels protect global compliance

1	// Illustrative: multi-window burn gate (conceptual)
2	public final class SloBurnGate {
3	private final double budgetFraction;
4	public boolean page(double burn5m, double burn1h) {
5	return burn5m > 14 * budgetFraction \|\| burn1h > 6 * budgetFraction;
6	}
7	}

1	def should_page(burn_5m: float, burn_1h: float, budget: float) -> bool:
2	return burn_5m > 14 * budget or burn_1h > 6 * budget

1	export function shouldPage(burn5m: number, burn1h: number, budget: number): boolean {
2	return burn5m > 14 * budget \|\| burn1h > 6 * budget;
3	}