Concurrency and scaling in GCP - Time & Space Complexity
When systems handle many tasks at once, understanding how time grows with more work helps us plan better.
We want to know how adding more users or requests affects the time to complete tasks.
Analyze the time complexity of scaling a service with concurrent requests.
// Pseudocode for handling concurrent requests
for each request in incoming_requests:
start new thread to process request
process request asynchronously
return response when done
This sequence shows how a service handles multiple requests at the same time using concurrency.
Look at what repeats as requests increase.
- Primary operation: Starting a new thread or process for each request.
- How many times: Once per incoming request.
Each new request adds one more concurrent operation.
| Input Size (n) | Approx. API Calls/Operations |
|---|---|
| 10 | 10 concurrent threads/processes |
| 100 | 100 concurrent threads/processes |
| 1000 | 1000 concurrent threads/processes |
Pattern observation: The number of concurrent operations grows directly with the number of requests.
Time Complexity: O(n)
This means the time to start handling all requests grows linearly as more requests come in.
[X] Wrong: "Adding more requests won't affect time because they run at the same time."
[OK] Correct: Even if requests run concurrently, starting and managing each one takes time and resources, so total work grows with requests.
Understanding how concurrency scales helps you design systems that handle many users smoothly, a key skill in cloud roles.
"What if we used a fixed number of worker threads instead of one per request? How would the time complexity change?"
Practice
Solution
Step 1: Understand concurrency meaning
Concurrency means how many tasks or requests can happen at once in one place.Step 2: Apply concurrency to cloud instances
In cloud services, concurrency controls how many requests a single instance handles simultaneously.Final Answer:
The number of requests one instance can handle at the same time -> Option CQuick Check:
Concurrency = requests per instance [OK]
- Confusing concurrency with total instances
- Thinking concurrency controls storage or bandwidth
- Mixing concurrency with scaling
Solution
Step 1: Identify correct flag for concurrency
The correct flag to set concurrency in Cloud Run is --concurrency.Step 2: Use update command for existing service
To change concurrency, use 'gcloud run services update SERVICE --concurrency=10'.Final Answer:
gcloud run services update SERVICE --concurrency=10 -> Option BQuick Check:
Concurrency flag is --concurrency [OK]
- Using --max-concurrency which is invalid
- Confusing concurrency with max-instances
- Trying to set concurrency on service creation instead of update
Solution
Step 1: Calculate needed instances for 20 requests with concurrency 5
Each instance can handle 5 requests at once, so 20 requests need 20/5 = 4 instances.Step 2: Apply max instances limit
The max instances is set to 3, so the service cannot create more than 3 instances.Final Answer:
3 instances -> Option DQuick Check:
Max instances limit caps instance count [OK]
- Ignoring max instances limit and choosing 4
- Confusing concurrency with max instances
- Assuming one instance per request
Solution
Step 1: Understand concurrency impact on app
High concurrency means many requests handled simultaneously by one instance, increasing resource use.Step 2: Link app crash to resource limits
If the app crashes, it likely cannot handle that many requests at once, causing memory or CPU overload.Final Answer:
The app cannot handle that many requests at once causing resource exhaustion -> Option AQuick Check:
Too high concurrency can crash app [OK]
- Blaming region instead of concurrency
- Assuming concurrency must be at least 100
- Ignoring app resource limits
Solution
Step 1: Balance concurrency and scaling for efficiency
Moderate concurrency lets each instance handle multiple requests, saving resources.Step 2: Allow max instances to scale high for spikes
High max instances lets the service add instances when traffic spikes, keeping performance.Final Answer:
Set concurrency to a moderate number (e.g., 10) and allow max instances to scale high -> Option AQuick Check:
Moderate concurrency + high max instances = efficient scaling [OK]
- Setting concurrency too low wastes instances
- Setting concurrency too high risks crashes
- Fixing max instances limits scaling
Ready to prove it?
Pass the test and this pattern moves unknown
