Why Load balancer types comparison in GCP? - Purpose & Use Cases

The Big Idea

What if your website could never slow down, no matter how many visitors arrive at once?

The Scenario

Imagine you run a popular website on just one server. When many people visit at once, the server gets overwhelmed and slows down or crashes. You try to manually direct visitors to different servers by changing settings one by one.

The Problem

This manual way is slow and confusing. You might send too many visitors to one server while others sit idle. It's easy to make mistakes, causing downtime and unhappy users.

The Solution

Load balancers automatically spread visitor traffic across many servers. They check which servers are healthy and send requests evenly, so no server gets too busy. This keeps your site fast and reliable without manual effort.

Before vs After

✗ Before

Send all traffic to server A
Change DNS to server B when A is busy

✓ After

Use load balancer to distribute traffic
Automatically route to healthy servers

What It Enables

Load balancers let your system handle many users smoothly and stay online even if some servers fail.

Real Life Example

When you shop online during a big sale, load balancers help the website stay fast by sharing visitors across many servers.

Key Takeaways

Manual traffic routing is slow and error-prone.

Load balancers automate traffic distribution and health checks.

This improves reliability, speed, and user experience.

Practice

1. Which GCP load balancer type is best suited for distributing HTTP and HTTPS traffic globally with SSL termination?

easy

A. TCP Proxy Load Balancer

B. Internal Load Balancer

C. Network Load Balancer

D. HTTP(S) Load Balancer

Solution

1. Step 1: Understand the traffic type

   HTTP and HTTPS traffic require Layer 7 (application layer) handling with SSL termination.

2. Step 2: Match load balancer capabilities

   HTTP(S) Load Balancer supports global distribution and SSL termination for web traffic.

3. Final Answer:

   HTTP(S) Load Balancer -> Option D

4. Quick Check:

   HTTP/HTTPS + SSL termination = HTTP(S) Load Balancer [OK]

Hint: Web traffic with SSL? Pick HTTP(S) Load Balancer [OK]

Common Mistakes:

• Confusing TCP Proxy with HTTP(S) for web traffic
• Choosing Network Load Balancer for HTTPS termination
• Using Internal Load Balancer for global traffic

2. Which GCP load balancer type uses a regional forwarding rule and supports TCP and UDP traffic without SSL termination?

easy

A. HTTP(S) Load Balancer

B. Network Load Balancer

C. TCP Proxy Load Balancer

D. Internal Load Balancer

Solution

1. Step 1: Identify the traffic and forwarding rule type

   TCP and UDP traffic with regional forwarding rules indicates a Layer 4 load balancer.

2. Step 2: Match with GCP load balancer types

   Network Load Balancer supports TCP/UDP traffic regionally without SSL termination.

3. Final Answer:

   Network Load Balancer -> Option B

4. Quick Check:

   TCP/UDP + regional + no SSL = Network Load Balancer [OK]

Hint: TCP/UDP regional traffic? Use Network Load Balancer [OK]

Common Mistakes:

• Choosing HTTP(S) Load Balancer for UDP traffic
• Confusing TCP Proxy with Network Load Balancer
• Selecting Internal Load Balancer for external traffic

3. Given this scenario: You want to load balance TCP traffic globally with SSL offloading. Which GCP load balancer type will you use?

client -> GCP LB -> backend instances (TCP with SSL offloading)

medium

A. TCP Proxy Load Balancer

B. Internal Load Balancer

C. Network Load Balancer

D. HTTP(S) Load Balancer

Solution

1. Step 1: Analyze traffic and SSL offloading need

   TCP traffic with SSL offloading requires Layer 4 proxy with SSL termination.

2. Step 2: Match with GCP load balancer types

   TCP Proxy Load Balancer supports global TCP traffic with SSL offloading.

3. Final Answer:

   TCP Proxy Load Balancer -> Option A

4. Quick Check:

   Global TCP + SSL offloading = TCP Proxy Load Balancer [OK]

Hint: Global TCP + SSL offload? Use TCP Proxy Load Balancer [OK]

Common Mistakes:

• Choosing Network Load Balancer which lacks SSL offloading
• Selecting HTTP(S) Load Balancer for TCP traffic
• Using Internal Load Balancer for external traffic

4. You configured an Internal Load Balancer but your clients outside the VPC cannot access the service. What is the most likely cause?

medium

A. Internal Load Balancer only supports traffic inside the VPC

B. You forgot to enable global forwarding rules

C. Internal Load Balancer does not support TCP traffic

D. You need to use HTTP(S) Load Balancer for internal traffic

Solution

1. Step 1: Understand Internal Load Balancer scope

   Internal Load Balancer is designed for traffic inside a VPC or connected networks only.

2. Step 2: Identify access limitation

   Clients outside the VPC cannot reach Internal Load Balancer because it does not expose external IPs.

3. Final Answer:

   Internal Load Balancer only supports traffic inside the VPC -> Option A

4. Quick Check:

   Internal LB = VPC-only traffic [OK]

Hint: Internal LB is VPC-only; external clients can't connect [OK]

Common Mistakes:

• Assuming Internal LB supports global forwarding
• Thinking Internal LB supports external TCP traffic
• Confusing Internal LB with HTTP(S) Load Balancer

5. You have a multi-region web app serving HTTP and HTTPS traffic with backend services in multiple zones. You want to minimize latency and provide automatic failover. Which GCP load balancer type should you choose and why?

hard

A. Network Load Balancer because it supports UDP and TCP globally

B. Internal Load Balancer because it routes traffic inside the VPC

C. HTTP(S) Load Balancer because it offers global load balancing with SSL termination and health checks

D. TCP Proxy Load Balancer because it handles TCP traffic with SSL offloading

Solution

1. Step 1: Analyze requirements for multi-region HTTP/HTTPS app

   Needs global load balancing, SSL termination, low latency, and failover.

2. Step 2: Match load balancer features

   HTTP(S) Load Balancer supports global distribution, SSL termination, health checks, and automatic failover.

3. Step 3: Exclude other options

   Network Load Balancer is regional and lacks SSL termination; Internal Load Balancer is internal-only; TCP Proxy is for TCP, not HTTP/HTTPS.

4. Final Answer:

   HTTP(S) Load Balancer because it offers global load balancing with SSL termination and health checks -> Option C

5. Quick Check:

   Multi-region HTTP/HTTPS + failover = HTTP(S) Load Balancer [OK]

Hint: Global web app? Pick HTTP(S) Load Balancer for SSL and failover [OK]

Common Mistakes:

• Choosing Network Load Balancer for HTTP/HTTPS global traffic
• Using Internal Load Balancer for external multi-region access
• Selecting TCP Proxy Load Balancer for HTTP traffic