Time Complexity: PATCH for partial updates
O(k)
0
0
PATCH for partial updates in Rest API - Time & Space Complexity
Understanding Time Complexity
When using PATCH requests to update parts of data, it's important to know how the time to process changes as the data grows.
We want to understand how the server's work changes when updating only some fields.
Scenario Under Consideration
Analyze the time complexity of the following PATCH request handler.
PATCH /users/{id}
Request body: { "email": "new@example.com" }
// Server-side pseudo-code
user = findUserById(id)
for each field in request body:
user[field] = request body[field]
save user
return updated user
This code updates only the fields sent in the PATCH request for a user.
Identify Repeating Operations
Look for repeated steps that take time depending on input size.
- Primary operation: Looping over fields in the request body to update user data.
- How many times: Once per field sent in the PATCH request.
How Execution Grows With Input
The time to update grows with how many fields you send to change.
| Input Size (fields to update) | Approx. Operations |
|---|---|
| 1 | 1 update operation |
| 5 | 5 update operations |
| 20 | 20 update operations |
Pattern observation: The work grows directly with the number of fields you update.
Final Time Complexity
Time Complexity: O(k)
This means the time grows linearly with the number of fields you want to update, not the total data size.
Common Mistake
[X] Wrong: "PATCH always takes the same time no matter how many fields are updated."
[OK] Correct: The server must process each field you send, so more fields mean more work and longer time.
Interview Connect
Understanding how partial updates scale helps you design efficient APIs and explain your choices clearly in interviews.
Self-Check
"What if the PATCH request included nested objects to update? How would that affect the time complexity?"