SLA and uptime tracking in Rest API - Time & Space Complexity

Time Complexity: SLA and uptime tracking

O(n)

Understanding Time Complexity

When tracking SLA and uptime via a REST API, it's important to know how the time to process requests grows as data increases.

We want to understand how the system handles more uptime records or checks.

Scenario Under Consideration

Analyze the time complexity of the following code snippet.

GET /uptime-records

// Server fetches all uptime records from database
// Then filters records within the requested time range
// Finally calculates uptime percentage for that period
    

This code fetches and processes uptime data to calculate SLA compliance.

Identify Repeating Operations

Identify the loops, recursion, array traversals that repeat.

• Primary operation: Looping through all uptime records to filter and calculate uptime.
• How many times: Once for each uptime record stored in the database.

How Execution Grows With Input

As the number of uptime records grows, the time to process them grows too.

Input Size (n)	Approx. Operations
10	10 checks
100	100 checks
1000	1000 checks

Pattern observation: The operations grow directly with the number of records.

Final Time Complexity

Time Complexity: O(n)

This means the time to calculate uptime grows linearly with the number of uptime records.

Common Mistake

[X] Wrong: "The time to calculate uptime stays the same no matter how many records there are."

[OK] Correct: Each record must be checked to calculate uptime, so more records mean more work.

Interview Connect

Understanding how data size affects API response time helps you design better systems and answer real-world questions confidently.

Self-Check

"What if the API cached pre-calculated uptime percentages? How would the time complexity change?"

Practice

1. What does SLA stand for in the context of uptime tracking?

easy

A. Service Level Agreement

B. System Log Analysis

C. Server Load Average

D. Standard Latency Assessment

Solution

1. Step 1: Understand SLA meaning

   SLA is a contract that defines expected service performance and uptime.

2. Step 2: Match SLA to options

   Only "Service Level Agreement" correctly describes this contract.

3. Final Answer:

   Service Level Agreement -> Option A

4. Quick Check:

   SLA = Service Level Agreement [OK]

Hint: Remember SLA means agreement on service quality [OK]

Common Mistakes:

• Confusing SLA with system logs
• Thinking SLA measures latency
• Mixing SLA with server load

2. Which HTTP method is typically used to retrieve uptime data from a REST API?

easy

A. POST

B. DELETE

C. PUT

D. GET

Solution

1. Step 1: Identify REST API methods for data retrieval

   GET method is used to request data without changing server state.

2. Step 2: Match method to uptime data retrieval

   Since uptime data is fetched, GET is the correct method.

3. Final Answer:

   GET -> Option D

4. Quick Check:

   Retrieve data with GET [OK]

Hint: Use GET to fetch data from REST APIs [OK]

Common Mistakes:

• Using POST to fetch data
• Confusing DELETE with retrieval
• Using PUT for reading data

3. Given this JSON response from an uptime API:

{"uptime_percentage": 99.5, "downtime_minutes": 30}

What is the actual uptime in minutes if the total period is 1440 minutes (1 day)?

medium

A. 1440 minutes

B. 1395 minutes

C. 1410 minutes

D. 1430 minutes

Solution

1. Step 1: Calculate uptime from total and downtime

   Uptime = Total minutes - Downtime minutes = 1440 - 30 = 1410 minutes.

2. Step 2: Confirm with options

   1410 minutes matches 1410 minutes. The percentage is a separate metric.

3. Final Answer:

   1410 minutes -> Option C

4. Quick Check:

   Uptime = 1440 - 30 = 1410 [OK]

Hint: Subtract downtime from total time for uptime [OK]

Common Mistakes:

• Using downtime as uptime
• Ignoring total period
• Confusing percentage with minutes

4. You have this REST API call to get uptime:

import requests
response = requests.get('https://api.example.com/uptime')
data = response.json()
uptime = data['up_time_percentage']

What is the error in this code?

medium

A. Incorrect key name 'up_time_percentage' instead of 'uptime_percentage'

B. Missing import for requests module

C. Using GET instead of POST method

D. No error, code is correct

Solution

1. Step 1: Check JSON key names

   The API returns key 'uptime_percentage', but code uses 'up_time_percentage'.

2. Step 2: Identify key mismatch error

   This causes a KeyError because the key name is incorrect.

3. Final Answer:

   Incorrect key name 'up_time_percentage' instead of 'uptime_percentage' -> Option A

4. Quick Check:

   Key name must match JSON exactly [OK]

Hint: Match JSON keys exactly to avoid errors [OK]

Common Mistakes:

• Typos in key names
• Using wrong HTTP method
• Forgetting to import requests

5. You want to check if a service meets its SLA of 99.9% uptime over a month (43200 minutes). The API returns:

{"uptime_percentage": 99.85}

Which statement correctly describes the SLA status?

hard

A. Service meets SLA because uptime is above 99.8%.

B. Service fails SLA because uptime is below 99.9%.

C. Service meets SLA because downtime is less than 60 minutes.

D. Service fails SLA because uptime percentage is not provided.

Solution

1. Step 1: Compare reported uptime to SLA target

   The SLA requires at least 99.9%, but actual uptime is 99.85%, which is less.

2. Step 2: Determine SLA compliance

   Since 99.85% < 99.9%, the service fails the SLA.

3. Final Answer:

   Service fails SLA because uptime is below 99.9% -> Option B

4. Quick Check:

   Actual uptime < SLA target means failure [OK]

Hint: Compare actual uptime directly to SLA percentage [OK]

Common Mistakes:

• Assuming close enough meets SLA
• Ignoring SLA threshold
• Confusing downtime with uptime