SLA, SLO, and SLI definitions in HLD - System Design Exercise

Design: Service Level Agreement (SLA), Service Level Objective (SLO), and Service Level Indicator (SLI) Definitions

In scope: Definitions, relationships, examples, and monitoring basics. Out of scope: Detailed implementation of monitoring tools or advanced reliability engineering.

Functional Requirements

FR1: Define SLA, SLO, and SLI clearly with examples

FR2: Explain how these terms relate to each other in service reliability

FR3: Show how to measure and monitor SLIs to meet SLOs and SLAs

FR4: Provide a simple example of a web service with SLA, SLO, and SLI

Non-Functional Requirements

NFR1: Definitions must be simple and jargon-free

NFR2: Examples must be relatable to common web services

NFR3: Focus on clarity and practical understanding

NFR4: No complex technical details beyond basic monitoring

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

Key Components

Service Level Indicator (SLI) metrics like uptime, latency, error rate

Service Level Objective (SLO) targets for these metrics

Service Level Agreement (SLA) as a formal contract based on SLOs

Monitoring and alerting tools to track SLIs

Design Patterns

Monitoring and alerting pattern

Feedback loop for continuous improvement

Contract-based service reliability

Reference Architecture

  +-------------------+       +-------------------+       +-------------------+
  |   Web Service     | <---> |   Monitoring      | <---> |   Alerting System  |
  +-------------------+       +-------------------+       +-------------------+
          |                          |                             |
          | SLIs (uptime, latency)   |                             |
          |------------------------->|                             |
                                     |                             |
                                     | Checks if SLOs met          |
                                     |---------------------------->|
                                                                   | Sends alerts if SLA violated

Components

Web Service

Any web server (e.g., Nginx, Apache, Node.js)

Provides the service whose reliability is measured

Monitoring

Prometheus, Datadog, or simple custom metrics

Collects SLIs such as uptime, latency, and error rate

Alerting System

PagerDuty, Opsgenie, or email alerts

Notifies when SLOs are not met, indicating SLA risk

Request Flow

1. User sends request to Web Service

2. Web Service processes request and responds

3. Monitoring system collects SLIs like response time and error rate

4. Monitoring compares SLIs against defined SLO targets

5. If SLOs are violated, Alerting System sends notifications

6. SLA defines the formal agreement based on these SLOs

Database Schema

Entities: - Service: id, name, description - SLI: id, service_id, metric_name (e.g., uptime, latency), measurement_method - SLO: id, service_id, sli_id, target_value (e.g., 99.9%), time_window - SLA: id, service_id, slo_id, penalty_terms Relationships: - Service 1:N SLI - Service 1:N SLO (each linked to one SLI) - Service 1:N SLA (each linked to one SLO)

Scaling Discussion

Bottlenecks

Monitoring system overwhelmed by high volume of metrics

Alerting system sending too many false positives

Difficulty in accurately measuring SLIs in distributed systems

Solutions

Use sampling and aggregation to reduce metric volume

Set proper thresholds and use anomaly detection to reduce false alerts

Implement distributed tracing and centralized logging for accurate measurement

Interview Tips

Time: Spend 10 minutes defining SLA, SLO, and SLI with examples; 10 minutes explaining their relationships and monitoring; 5 minutes discussing challenges and scaling; 5 minutes for questions and clarifications.

Clear distinction: SLA is a contract, SLO is a target, SLI is a metric

SLIs must be measurable and meaningful

SLOs guide operational goals and alerting

SLAs formalize commitments and consequences

Monitoring and alerting are essential for maintaining reliability

Practice

1. What does SLA stand for in system design and what does it represent?

easy

A. Service Level Objective; a specific target for system reliability

B. Service Level Indicator; a metric to measure system performance

C. System Load Average; the average system load over time

D. Service Level Agreement; the overall service promise between provider and customer

Solution

1. Step 1: Understand SLA meaning

   SLA stands for Service Level Agreement, which is a formal contract or promise about the service quality.

2. Step 2: Identify SLA role

   It defines the overall service promise between the provider and the customer, including availability, performance, and support.

3. Final Answer:

   Service Level Agreement; the overall service promise between provider and customer -> Option D

4. Quick Check:

   SLA = overall service promise [OK]

Hint: SLA is the big promise, not the metric or target [OK]

Common Mistakes:

• Confusing SLA with SLO or SLI
• Thinking SLA is a metric
• Mixing SLA with system load terms

2. Which of the following correctly defines an SLI?

easy

A. A contract between provider and customer

B. A specific goal to meet the service promise

C. A metric used to measure service performance

D. A penalty for failing service levels

Solution

1. Step 1: Define SLI

   SLI stands for Service Level Indicator, which is a measurable metric that shows how well the service is performing.

2. Step 2: Differentiate from SLO and SLA

   Unlike SLO (goal) or SLA (contract), SLI is the actual measurement like latency, error rate, or uptime percentage.

3. Final Answer:

   A metric used to measure service performance -> Option C

4. Quick Check:

   SLI = metric [OK]

Hint: SLI is the number you measure, not the goal or contract [OK]

Common Mistakes:

• Confusing SLI with SLO or SLA
• Thinking SLI is a goal or agreement
• Mixing SLI with penalties

3. Given the following definitions:
SLA: 99.9% uptime per month
SLO: 99.95% uptime per month
SLI: Measured uptime percentage
What happens if the measured uptime is 99.92% for the month?

medium

A. SLA is met but SLO is violated

B. Both SLA and SLO are met

C. Both SLA and SLO are violated

D. SLA is violated but SLO is met

Solution

1. Step 1: Compare measured uptime with SLA

   The SLA requires 99.9% uptime. The measured uptime is 99.92%, which is higher, so SLA is met.

2. Step 2: Compare measured uptime with SLO

   The SLO target is 99.95%. The measured uptime 99.92% is less than 99.95%, so SLO is violated.

3. Final Answer:

   SLA is met but SLO is violated -> Option A

4. Quick Check:

   Measured uptime 99.92% < SLO 99.95% but > SLA 99.9% [OK]

Hint: Check if measured metric meets SLO first, then SLA [OK]

Common Mistakes:

• Mixing up SLA and SLO thresholds
• Assuming meeting SLA means meeting SLO
• Ignoring the difference between SLA and SLO

4. You have these definitions:
SLA: 99.9% uptime
SLO: 99.95% uptime
SLI: uptime percentage
Measured uptime is 99.85%. Which is the error in this statement?
"Since uptime is 99.85%, both SLA and SLO are met."

medium

A. The measured uptime is below SLA, so SLA is violated

B. The measured uptime is above SLO, so SLO is met

C. SLI is not uptime percentage

D. SLA and SLO are the same, so both are met

Solution

1. Step 1: Check measured uptime against SLA

   SLA requires 99.9% uptime. Measured uptime is 99.85%, which is less, so SLA is violated.

2. Step 2: Check measured uptime against SLO

   SLO requires 99.95% uptime. Measured uptime 99.85% is less, so SLO is also violated.

3. Final Answer:

   The measured uptime is below SLA, so SLA is violated -> Option A

4. Quick Check:

   99.85% < 99.9% SLA means SLA violated [OK]

Hint: Always compare measured uptime to SLA threshold first [OK]

Common Mistakes:

• Assuming 99.85% is above 99.9%
• Confusing SLI with SLO or SLA
• Thinking SLA and SLO are identical

5. A company promises 99.9% uptime in its SLA. It sets an SLO of 99.95% uptime and uses error rate as the SLI. If the error rate increases causing uptime to drop to 99.85%, what should the company do to maintain trust and meet SLA?

hard

A. Change the SLA to match the current uptime

B. Improve system reliability to reduce error rate below SLO target

C. Ignore the SLI since SLA is the only important metric

D. Increase the error rate threshold in SLI to match uptime

Solution

1. Step 1: Understand the relationship between SLA, SLO, and SLI

   SLA is the promise (99.9%), SLO is the goal (99.95%), and SLI is the metric (error rate) used to measure uptime.

2. Step 2: Analyze the impact of increased error rate

   Higher error rate lowers uptime to 99.85%, which violates both SLO and SLA targets, risking customer trust.

3. Step 3: Determine corrective action

   The company should improve system reliability to reduce error rate and restore uptime above SLA and SLO levels.

4. Final Answer:

   Improve system reliability to reduce error rate below SLO target -> Option B

5. Quick Check:

   Fix error rate to meet SLO and SLA [OK]

Hint: Fix the metric causing SLA breach, don't change promises [OK]

Common Mistakes:

• Changing SLA instead of fixing system
• Ignoring SLI importance
• Adjusting thresholds to hide problems