API monitoring and alerting in Rest API - Time & Space Complexity

Time Complexity: API monitoring and alerting

O(n)

Understanding Time Complexity

When monitoring APIs, we want to know how the time to check and alert changes as the number of API calls grows.

We ask: How does the work increase when more API requests happen?

Scenario Under Consideration

Analyze the time complexity of the following code snippet.

// Pseudocode for API monitoring
function monitorAPIs(apiCalls) {
  for (let call of apiCalls) {
    if (call.status === 'error') {
      sendAlert(call);
    }
  }
}

function sendAlert(call) {
  // send alert for the failed API call
}
    

This code checks each API call for errors and sends an alert if needed.

Identify Repeating Operations

Identify the loops, recursion, array traversals that repeat.

• Primary operation: Looping through each API call in the list.
• How many times: Once for every API call received.

How Execution Grows With Input

As the number of API calls grows, the time to check each one grows too.

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

Pattern observation: The work grows directly with the number of API calls.

Final Time Complexity

Time Complexity: O(n)

This means the time to monitor grows in a straight line with the number of API calls.

Common Mistake

[X] Wrong: "Checking all API calls happens instantly no matter how many there are."

[OK] Correct: Each API call needs to be checked one by one, so more calls mean more work and more time.

Interview Connect

Understanding how monitoring scales helps you design systems that stay reliable as traffic grows. This skill shows you can think about real-world system behavior.

Self-Check

"What if we only checked API calls that failed instead of all calls? How would the time complexity change?"

Practice

1. What is the main purpose of API monitoring in DevOps?

easy

A. To design the API user interface

B. To write new API endpoints

C. To regularly check if the API is working correctly

D. To store API data permanently

Solution

1. Step 1: Understand API monitoring

   API monitoring means checking the API often to see if it works well without errors.

2. Step 2: Identify the main goal

   The main goal is to ensure the API is available and responds correctly to requests.

3. Final Answer:

   To regularly check if the API is working correctly -> Option C

4. Quick Check:

   API monitoring = regular checks [OK]

Hint: Monitoring means checking often if API works [OK]

Common Mistakes:

• Confusing monitoring with API design
• Thinking monitoring stores data
• Mixing monitoring with coding new endpoints

2. Which of the following is the correct way to set up an alert for API downtime in a monitoring tool?

easy

A. Trigger alert if API response time is less than 100ms

B. Trigger alert if API documentation changes

C. Trigger alert if API returns status code 200

D. Trigger alert if API returns status code 500 or no response

Solution

1. Step 1: Understand alert conditions for downtime

   An alert for downtime should trigger when the API fails or does not respond, such as status code 500 or no response.

2. Step 2: Evaluate options

   Trigger alert if API returns status code 500 or no response correctly triggers alert on error or no response. Other options either alert on success or unrelated events.

3. Final Answer:

   Trigger alert if API returns status code 500 or no response -> Option D

4. Quick Check:

   Alert on errors or no response = Trigger alert if API returns status code 500 or no response [OK]

Hint: Alert on errors or no response, not success [OK]

Common Mistakes:

• Alerting on successful responses
• Alerting on unrelated changes like docs
• Using wrong status codes for alerts

3. Given this monitoring script snippet:

response = requests.get('https://api.example.com/data')
if response.status_code != 200:
    send_alert('API error detected')

What happens if the API returns status code 404?

medium

A. No alert is sent

B. An alert is sent with message 'API error detected'

C. The script crashes with an error

D. The script retries the request automatically

Solution

1. Step 1: Analyze the condition in the script

   The script sends an alert if the status code is not 200.

2. Step 2: Check the status code 404

   Since 404 is not 200, the condition is true and alert is sent.

3. Final Answer:

   An alert is sent with message 'API error detected' -> Option B

4. Quick Check:

   Status code 404 triggers alert [OK]

Hint: Alert triggers if status code not 200 [OK]

Common Mistakes:

• Thinking 404 is success
• Assuming script crashes on 404
• Believing script retries automatically

4. You wrote this alert rule:

if response.status_code = 500:
    send_alert('Server error')

Why does this rule not work as expected?

medium

A. The comparison operator should be '==' not '='

B. The status code 500 is not an error

C. send_alert function is missing parentheses

D. The API URL is missing

Solution

1. Step 1: Identify the operator used

   The code uses '=' which is assignment, not comparison.

2. Step 2: Correct operator for comparison

   To compare values, '==' must be used instead of '='.

3. Final Answer:

   The comparison operator should be '==' not '=' -> Option A

4. Quick Check:

   Use '==' for comparison [OK]

Hint: Use '==' to compare values, '=' assigns [OK]

Common Mistakes:

• Using '=' instead of '==' in conditions
• Thinking 500 is not an error
• Ignoring syntax errors in conditions

5. You want to monitor an API that sometimes returns status 429 (too many requests) temporarily. Which alerting strategy best avoids false alarms?

hard

A. Alert only if 429 responses occur continuously for 5 minutes

B. Alert immediately on any 429 response

C. Ignore 429 responses completely

D. Alert only if 429 responses are followed by 200 responses

Solution

1. Step 1: Understand 429 status meaning

   Status 429 means too many requests temporarily; it may resolve quickly.

2. Step 2: Choose alerting strategy to avoid false alarms

   Alerting immediately on one 429 may cause false alarms; waiting for continuous 429s for 5 minutes reduces noise.

3. Final Answer:

   Alert only if 429 responses occur continuously for 5 minutes -> Option A

4. Quick Check:

   Delay alerts on temporary errors to reduce false alarms [OK]

Hint: Wait before alerting on temporary errors [OK]

Common Mistakes:

• Alerting immediately on every 429
• Ignoring 429 which may hide real issues
• Alerting on 429 followed by success