SLA and uptime tracking in Rest API - Time & Space 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.
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 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.
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.
Time Complexity: O(n)
This means the time to calculate uptime grows linearly with the number of uptime records.
[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.
Understanding how data size affects API response time helps you design better systems and answer real-world questions confidently.
"What if the API cached pre-calculated uptime percentages? How would the time complexity change?"