REST API serving with FastAPI in MLOps - Time & Space Complexity

Time Complexity: REST API serving with FastAPI

O(1)

Understanding Time Complexity

When we serve a REST API using FastAPI, we want to know how the time to handle requests changes as more requests come in.

We ask: How does the server's work grow when the number of requests increases?

Scenario Under Consideration

Analyze the time complexity of the following FastAPI endpoint code.

from fastapi import FastAPI

app = FastAPI()

items = {"foo": "The Foo item", "bar": "The Bar item"}

@app.get("/items/{item_id}")
async def read_item(item_id: str):
    return {"item_id": item_id, "description": items.get(item_id, "Not found")}

This code defines a simple API that returns an item description by its ID from a dictionary.

Identify Repeating Operations

Identify the loops, recursion, array traversals that repeat.

• Primary operation: Dictionary lookup for the requested item ID.
• How many times: Once per API request.

How Execution Grows With Input

Each request looks up the item ID in the dictionary. The time to find the item does not grow much as the dictionary grows.

Input Size (number of items)	Approx. Operations per request
10	About 1 lookup operation
100	Still about 1 lookup operation
1000	Still about 1 lookup operation

Pattern observation: The lookup time stays almost the same no matter how many items are stored.

Final Time Complexity

Time Complexity: O(1)

This means each request takes about the same time to process, no matter how many items exist.

Common Mistake

[X] Wrong: "The time to find an item grows as the number of items grows."

[OK] Correct: Dictionary lookups in Python are very fast and do not slow down much as the dictionary gets bigger.

Interview Connect

Understanding how API request handling scales helps you design fast and reliable services, a key skill in real-world software development.

Self-Check

What if we changed the dictionary to a list and searched items one by one? How would the time complexity change?

Practice

1. What is the main purpose of using FastAPI in serving machine learning models?

easy

A. To train machine learning models faster

B. To create fast and simple REST APIs for model serving

C. To store large datasets efficiently

D. To visualize model performance graphs

Solution

1. Step 1: Understand FastAPI's role

   FastAPI is a web framework used to build APIs quickly and simply.

2. Step 2: Connect to model serving

   It is commonly used to serve machine learning models via REST APIs for easy access.

3. Final Answer:

   To create fast and simple REST APIs for model serving -> Option B

4. Quick Check:

   FastAPI = REST API serving [OK]

Hint: FastAPI is for building APIs, not training or storage [OK]

Common Mistakes:

• Confusing API serving with model training
• Thinking FastAPI handles data storage
• Assuming FastAPI is for visualization

2. Which of the following is the correct way to define a GET endpoint in FastAPI?

easy

A. @app.route('/items', method='GET')
def read_items():
return {'items': []}

B. @app.post('/items')
def read_items():
return {'items': []}

C. @app.get('/items')
def read_items():
print('items')

D. @app.get('/items')
def read_items():
return {'items': []}

Solution

1. Step 1: Identify correct decorator for GET

   FastAPI uses @app.get() to define GET endpoints.

2. Step 2: Check function returns JSON response

   The function should return a dictionary to send JSON; print statement does not return data.

3. Final Answer:

   @app.get('/items')\ndef read_items():\n return {'items': []} -> Option D

4. Quick Check:

   @app.get() + return dict = correct GET endpoint [OK]

Hint: Use @app.get() and return dict for GET endpoints [OK]

Common Mistakes:

• Using @app.post() for GET endpoints
• Using print instead of return
• Using Flask-style @app.route() syntax

3. What will be the output when you call the following FastAPI endpoint?

@app.get('/hello')
def say_hello():
    return {'message': 'Hello, FastAPI!'}

medium

A. {\"message\": \"Hello, FastAPI!\"}

B. Hello, FastAPI!

C. Error: Missing return type

D. 404 Not Found

Solution

1. Step 1: Analyze endpoint return value

   The function returns a dictionary with key 'message' and value 'Hello, FastAPI!'.

2. Step 2: Understand FastAPI response format

   FastAPI automatically converts dict to JSON response with the same structure.

3. Final Answer:

   {"message": "Hello, FastAPI!"} -> Option A

4. Quick Check:

   Return dict = JSON response with same keys [OK]

Hint: Return dict from endpoint gives JSON response [OK]

Common Mistakes:

• Expecting plain string instead of JSON
• Thinking missing return type causes error
• Assuming endpoint path is incorrect

4. Identify the error in this FastAPI POST endpoint code:

@app.post('/predict')
def predict(data: dict):
    return {'result': data['value'] * 2}

medium

A. Missing request body declaration with Pydantic model

B. Incorrect HTTP method, should be GET

C. Function missing return statement

D. Syntax error in decorator

Solution

1. Step 1: Check parameter type for POST data

   FastAPI requires request body to be declared with Pydantic models or Body for parsing JSON.

2. Step 2: Understand why dict alone is insufficient

   Using plain dict as parameter does not parse JSON body automatically, causing validation error.

3. Final Answer:

   Missing request body declaration with Pydantic model -> Option A

4. Quick Check:

   POST body needs Pydantic model or Body [OK]

Hint: Use Pydantic models for POST request bodies [OK]

Common Mistakes:

• Using plain dict instead of Pydantic model
• Confusing POST with GET method
• Forgetting to return a response

5. You want to serve a machine learning model prediction via FastAPI. Which approach correctly handles input validation and prediction?

from pydantic import BaseModel

class InputData(BaseModel):
    feature1: float
    feature2: float

@app.post('/predict')
def predict(data: InputData):
    result = model.predict([[data.feature1, data.feature2]])
    return {'prediction': result[0]}

What is the main advantage of this design?

hard

A. It skips input validation for faster response

B. It trains the model on each request

C. It validates input data types automatically before prediction

D. It returns raw model object instead of prediction

Solution

1. Step 1: Understand Pydantic model role

   InputData class validates that feature1 and feature2 are floats before function runs.

2. Step 2: Connect validation to prediction safety

   This prevents invalid data from reaching model.predict, avoiding runtime errors.

3. Final Answer:

   It validates input data types automatically before prediction -> Option C

4. Quick Check:

   Pydantic = automatic input validation [OK]

Hint: Use Pydantic models to validate inputs before prediction [OK]

Common Mistakes:

• Thinking model retrains on each request
• Skipping validation causes errors
• Returning model object instead of prediction