Functions with HTTP triggers in Azure - Time & Space Complexity
Start learning this pattern below
Jump into concepts and practice - no test required
When using Azure Functions triggered by HTTP requests, it's important to understand how the number of requests affects the system's work.
We want to know how the function's execution scales as more HTTP calls come in.
Analyze the time complexity of the following Azure Function triggered by HTTP requests.
[FunctionName("HttpTriggerFunction")]
public static async Task Run(
[HttpTrigger(AuthorizationLevel.Function, "get", "post", Route = null)] HttpRequest req,
ILogger log)
{
log.LogInformation("Processing HTTP request.");
string name = req.Query["name"];
return new OkObjectResult($"Hello, {name}");
}
This function responds to each HTTP request by reading a query parameter and returning a greeting.
Identify the API calls, resource provisioning, data transfers that repeat.
- Primary operation: The function execution triggered by each HTTP request.
- How many times: Once per HTTP request received.
Each new HTTP request causes one function execution, so the work grows directly with the number of requests.
| Input Size (n) | Approx. Api Calls/Operations |
|---|---|
| 10 | 10 function executions |
| 100 | 100 function executions |
| 1000 | 1000 function executions |
Pattern observation: The total work increases linearly as the number of HTTP requests increases.
Time Complexity: O(n)
This means the total execution time grows in direct proportion to the number of HTTP requests received.
[X] Wrong: "The function runs once and handles all requests together."
[OK] Correct: Each HTTP request triggers a separate function execution, so work adds up with each request, not just once.
Understanding how serverless functions scale with incoming requests helps you design responsive and cost-effective cloud solutions.
"What if the function called another API inside for each request? How would that affect the time complexity?"
Practice
Solution
Step 1: Understand the role of HTTP triggers
HTTP triggers start a function when a web request is received.Step 2: Compare with other triggers
Other triggers like timers schedule functions, but HTTP triggers respond to web calls.Final Answer:
It runs the function when it receives a web request. -> Option BQuick Check:
HTTP trigger = runs on web request [OK]
- Confusing HTTP trigger with timer trigger
- Thinking HTTP trigger stores data
- Assuming HTTP trigger sends emails
Solution
Step 1: Identify HTTP trigger binding
The correct binding type for HTTP trigger is "httpTrigger" with direction "in".Step 2: Check authLevel and methods
authLevel "function" and methods ["get"] are valid properties for HTTP triggers.Final Answer:
"bindings": [{ "type": "httpTrigger", "direction": "in", "authLevel": "function", "methods": ["get"] }] -> Option AQuick Check:
HTTP trigger binding = type "httpTrigger" [OK]
- Using timerTrigger or blobTrigger instead of httpTrigger
- Missing authLevel property
- Wrong direction value
import logging
import azure.functions as func
def main(req: func.HttpRequest) -> func.HttpResponse:
name = req.params.get('name')
if not name:
return func.HttpResponse("Please pass a name", status_code=400)
return func.HttpResponse(f"Hello, {name}!")Solution
Step 1: Check request parameter handling
The function looks for 'name' in query parameters. If missing, it returns a 400 response with message "Please pass a name".Step 2: Analyze given request
The question states a GET request is sent but does not mention a 'name' parameter, so name will be None.Final Answer:
Please pass a name -> Option DQuick Check:
No name param = "Please pass a name" response [OK]
- Assuming default name is 'Alice' or 'World'
- Ignoring the 400 status code response
- Confusing request body with query parameters
{
"bindings": [
{
"type": "httpTrigger",
"direction": "in",
"authLevel": "anonymous",
"methods": ["post"]
},
{
"type": "httpTrigger",
"direction": "out"
}
]
}What is the error in this configuration?
Solution
Step 1: Review input and output bindings
The input binding uses "httpTrigger" which is correct for HTTP triggers.Step 2: Identify output binding error
The output binding incorrectly uses "httpTrigger"; it should be "http" with direction "out" for HTTP responses.Final Answer:
The output binding type should be "http" not "httpTrigger". -> Option AQuick Check:
HTTP output binding = type "http" [OK]
- Using "httpTrigger" as output binding type incorrectly
- Confusing input and output binding types
- Setting wrong direction for output binding
Solution
Step 1: Check authLevel and input handling
authLevel "function" is set in function.json (not shown), so code must handle query param 'name' safely.Step 2: Validate JSON response and error handling
import azure.functions as func import json def main(req: func.HttpRequest) -> func.HttpResponse: name = req.params.get('name') if not name: return func.HttpResponse(json.dumps({'error': 'Missing name'}), status_code=400, mimetype='application/json') return func.HttpResponse(json.dumps({'message': f'Hello, {name}!'}), mimetype='application/json') uses json.dumps to create proper JSON for both error ({'error': 'Missing name'}) and success ({'message': f'Hello, {name}!'}), with mimetype='application/json' and status_code=400 for errors.Step 3: Compare other options
A returns plain text error and f-string JSON-like string; C uses get_json() instead of params; D uses text/plain mimetype.Final Answer:
Uses json.dumps and mimetype='application/json' for both success and error JSON responses. -> Option CQuick Check:
json.dumps for JSON error and success with application/json mimetype [OK]
- Returning JSON as plain string without json.dumps
- Using wrong mimetype for JSON
- Reading JSON body instead of query parameters
