Serverless vs GKE decision in GCP - Performance Comparison

Time Complexity: Serverless vs GKE decision

O(n)

Understanding Time Complexity

When choosing between Serverless and GKE, it's important to understand how the time to handle requests grows as demand increases.

We want to see how the number of operations changes when more users or tasks come in.

Scenario Under Consideration

Analyze the time complexity of handling incoming requests using Serverless functions versus GKE pods.

// Serverless example
for each request:
  invoke Cloud Function

// GKE example
for each request:
  route to pod in GKE cluster

This shows how requests are processed differently: Serverless spins up functions on demand, GKE routes to existing pods.

Identify Repeating Operations

Look at what happens repeatedly as requests come in.

• Primary operation: Invoking a Cloud Function or routing to a GKE pod for each request.
• How many times: Once per request, scaling with the number of requests.

How Execution Grows With Input

As the number of requests grows, the system must handle more invocations or routes.

Input Size (n)	Approx. API Calls/Operations
10	10 function invocations or pod routes
100	100 function invocations or pod routes
1000	1000 function invocations or pod routes

Each new request adds one more operation, so the total grows directly with the number of requests.

Final Time Complexity

Time Complexity: O(n)

This means the work grows in a straight line with the number of requests; more requests mean more operations.

Common Mistake

[X] Wrong: "Serverless always handles any number of requests instantly without extra cost."

[OK] Correct: Each request still triggers a function call, so the total work grows with requests, and cold starts can add delay.

Interview Connect

Understanding how request handling scales helps you explain trade-offs clearly and shows you grasp real cloud workload behavior.

Self-Check

What if we batch multiple requests together before processing? How would the time complexity change?