Request-based auto scaling in GCP - Step-by-Step Execution

Process Flow - Request-based auto scaling

Incoming Requests

↓

Monitor Request Rate

↓

Compare with Threshold

↓

Scale Up

↓

Adjust Instances

↓

Handle Requests with New Capacity

↓

Repeat Monitoring

The system watches incoming requests, checks if they are above or below a set limit, then adds or removes instances to handle the load efficiently.

Execution Sample

GCP

1. Monitor request count every minute
2. If requests > 1000, add 1 instance
3. If requests < 500, remove 1 instance
4. Keep instances between 1 and 5

This simple rule adjusts the number of instances based on request volume to keep performance steady.

Process Table

Minute	Request Count	Condition (>1000?)	Condition (<500?)	Action	Instances Before	Instances After
1	800	No	No	No change	2	2
2	1200	Yes	No	Scale Up +1	2	3
3	1500	Yes	No	Scale Up +1	3	4
4	400	No	Yes	Scale Down -1	4	3
5	300	No	Yes	Scale Down -1	3	2
6	2000	Yes	No	Scale Up +1	2	3
7	600	No	No	No change	3	3
8	450	No	Yes	Scale Down -1	3	2
9	100	No	Yes	Scale Down -1	2	1
10	1100	Yes	No	Scale Up +1	1	2
11	400	No	Yes	Scale Down -1	2	1
12	3000	Yes	No	Scale Up +1	1	2
13	3500	Yes	No	Scale Up +1	2	3
14	4000	Yes	No	Scale Up +1	3	4
15	4500	Yes	No	Scale Up +1	4	5
16	5000	Yes	No	No change (max reached)	5	5
17	200	No	Yes	Scale Down -1	5	4
18	100	No	Yes	Scale Down -1	4	3
19	50	No	Yes	Scale Down -1	3	2
20	400	No	Yes	Scale Down -1	2	1
21	300	No	Yes	No change (min reached)	1	1

💡 At minute 21, instances are at minimum (1), so no further scale down occurs despite low requests.

Status Tracker

Variable	Start	After 1	After 2	After 3	After 4	After 5	After 6	After 7	After 8	After 9	After 10	After 11	After 12	After 13	After 14	After 15	After 16	After 17	After 18	After 19	After 20	After 21
Instances	2	2	3	4	3	2	3	3	2	1	2	1	2	3	4	5	5	4	3	2	1	1

Key Moments - 3 Insights

Why does the number of instances not go below 1 even when requests are very low?

The system has a minimum limit of 1 instance to ensure the service is always available, as shown in execution_table rows 9, 11, 20, and 21 where scale down stops at 1.

What happens when the request count is exactly 1000 or 500?

The conditions check strictly greater than 1000 and less than 500, so at exactly 1000 or 500 no scaling action occurs. This is implied by the conditions in the execution_table.

Why does scaling up stop at 5 instances even if requests keep increasing?

There is a maximum limit of 5 instances to control costs and resource use, as seen at minute 16 where requests are high but instances remain at 5.

Visual Quiz - 3 Questions

Look at the execution_table at minute 4. What action is taken and why?

A Scale Up by 1 because requests > 1000

B No change because requests are between 500 and 1000

C Scale Down by 1 because requests < 500

D Scale Up by 2 because requests are very high

💡 Hint

Check the 'Request Count' and 'Condition (<500?)' columns at minute 4 in execution_table.

At which minute does the number of instances first reach the maximum limit?

A Minute 13

B Minute 15

C Minute 16

D Minute 14

💡 Hint

Look at the 'Instances After' column in execution_table and find when it first hits 5.

If the minimum instances were set to 2 instead of 1, what would happen at minute 21?

A Instances would stay at 2

B Instances would scale down to 0

C Instances would stay at 1

D Instances would scale up to 3

💡 Hint

Refer to variable_tracker for Instances and the minimum limit rule explained in key_moments.

Concept Snapshot

Request-based auto scaling watches incoming requests.
If requests go above a high threshold, it adds instances.
If requests fall below a low threshold, it removes instances.
Instances stay within set minimum and maximum limits.
This keeps service responsive and cost-effective.

Full Transcript

Request-based auto scaling is a way to adjust the number of server instances based on how many requests come in. The system checks the request count every minute. If the count is higher than a set limit, it adds an instance to handle the load. If the count is lower than another limit, it removes an instance to save resources. The number of instances never goes below a minimum or above a maximum to keep the service stable and cost-controlled. This process repeats continuously to match capacity with demand.

Practice

1. What does request-based auto scaling primarily adjust in a cloud service?

easy

A. The number of server instances based on incoming requests

B. The amount of storage space available

C. The network bandwidth allocation

D. The security settings of the service

Solution

1. Step 1: Understand the purpose of request-based auto scaling

   Request-based auto scaling changes resources based on the number of incoming requests to handle load efficiently.

2. Step 2: Identify what is adjusted

   The main resource adjusted is the number of server instances to match demand.

3. Final Answer:

   The number of server instances based on incoming requests -> Option A

4. Quick Check:

   Scaling adjusts instances = A [OK]

Hint: Auto scaling changes instance count, not storage or security [OK]

Common Mistakes:

• Confusing scaling with storage or bandwidth changes
• Thinking it adjusts security settings
• Assuming it changes fixed resources regardless of requests

2. Which of the following is the correct way to set the minimum number of instances in a GCP service YAML configuration for request-based auto scaling?

easy

A. min-instances: 2

B. minInstances: 2

C. minimum_instances: 2

D. min_instances: 2

Solution

1. Step 1: Recall GCP YAML syntax for scaling parameters

   GCP uses kebab-case for configuration keys like min-instances.

2. Step 2: Identify the correct key format

   The correct key to set minimum instances is min-instances, not camelCase or underscored.

3. Final Answer:

   min-instances: 2 -> Option A

4. Quick Check:

   Use kebab-case keys like min-instances [OK]

Hint: Use kebab-case keys like min-instances in GCP YAML [OK]

Common Mistakes:

• Using camelCase or underscores instead of kebab-case
• Misspelling the key name
• Confusing min-instances with max-instances

3. Given this snippet of a GCP service configuration for request-based auto scaling:

concurrency: 10
min-instances: 1
max-instances: 5

What happens when the service receives 50 simultaneous requests?

medium

A. The service scales down to 0 instances to save cost

B. The service stays at 1 instance because min-instances is set

C. The service scales up to 10 instances because concurrency is 10

D. The service scales up to 5 instances to handle the load

Solution

1. Step 1: Understand concurrency and instance limits

   Concurrency 10 means each instance can handle 10 requests at once. Max-instances is 5, min-instances is 1.

2. Step 2: Calculate needed instances for 50 requests

   50 requests / 10 concurrency = 5 instances needed, which matches max-instances.

3. Final Answer:

   The service scales up to 5 instances to handle the load -> Option D

4. Quick Check:

   Requests/concurrency = instances needed = 5 [OK]

Hint: Divide requests by concurrency, respect max-instances limit [OK]

Common Mistakes:

• Ignoring max-instances limit
• Confusing concurrency with max-instances
• Assuming scaling down when load increases

4. You configured a GCP service with:

concurrency: 5
min-instances: 2
max-instances: 4

But the service never scales above 2 instances even under heavy load. What is the most likely cause?

medium

A. The concurrency value is too high, limiting scaling

B. The max-instances value is too low to allow scaling beyond 2

C. The min-instances value is preventing scaling down

D. The service needs a restart to apply scaling changes

Solution

1. Step 1: Analyze max-instances and min-instances settings

   Max-instances is set to 4, min-instances is 2. Scaling cannot exceed max-instances.

2. Step 2: Understand why scaling stops at 2

   If the service never goes above 2 instances, max-instances might be set too low or misinterpreted.

3. Final Answer:

   The max-instances value is too low to allow scaling beyond 2 -> Option B

4. Quick Check:

   Max-instances limits max scale = B [OK]

Hint: Check max-instances to allow scaling beyond min-instances [OK]

Common Mistakes:

• Confusing min-instances with max-instances
• Assuming concurrency limits scaling up
• Forgetting to check applied config values

5. You want to optimize cost and performance for a GCP service that experiences unpredictable traffic spikes. Which configuration best balances fast scaling up and cost savings during idle times?

hard

A. Set concurrency to 1, min-instances to 0, max-instances to 10

B. Set concurrency to 50, min-instances to 5, max-instances to 5

C. Set concurrency to 10, min-instances to 1, max-instances to 10

D. Set concurrency to 100, min-instances to 10, max-instances to 20

Solution

1. Step 1: Understand concurrency and instance settings impact

   Lower concurrency means more instances needed; min-instances controls baseline cost; max-instances limits scale.

2. Step 2: Evaluate options for balancing cost and performance

   Set concurrency to 10, min-instances to 1, max-instances to 10 uses moderate concurrency (10), low min-instances (1) to save cost, and high max-instances (10) to handle spikes.

3. Final Answer:

   Set concurrency to 10, min-instances to 1, max-instances to 10 -> Option C

4. Quick Check:

   Moderate concurrency + low min + high max = balanced scaling [OK]

Hint: Moderate concurrency with low min and high max balances cost and spikes [OK]

Common Mistakes:

• Setting concurrency too low causing many instances
• Setting min-instances too high increasing cost
• Setting max-instances too low limiting scaling