Interview questions

Interview questions (with the counter-questions you'll get)

Q1. What does a load balancer do, and why do we need one?

They're testing: the basics, plus why it matters.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** It sits in front of a pool of servers and spreads incoming requests across the healthy ones. It gives clients one stable address, keeps load even, removes failed servers automatically through health checks, and lets us add, remove or replace servers without downtime. It relies on the servers being stateless, so any server can handle any request.
3
4**Counter-questions:**
5- *"Isn't DNS round-robin enough?"* → It's a rough form of load balancing, but it can't see server health or load in real time, and DNS caching delays changes. A load balancer reacts in seconds (Chapter 4).
6
7**Trap:** describing only "it distributes traffic" without health checks or scaling.

Q2. L4 vs L7 load balancing?

They're testing: knowing what each layer can see.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** L4 works on TCP or UDP connections using IP addresses and ports; it's fast, cheap and protocol-agnostic but can't see inside requests. L7 understands HTTP, so it can route by path, host or header, terminate TLS, use cookies for stickiness and retry requests, at the cost of more processing. Many setups put a fast L4 layer in front of L7 proxies.
3
4**Counter-questions:**
5- *"Which would you use for a database?"* → L4, since the protocol isn't HTTP and there's nothing at layer 7 to route on.
6
7**Trap:** not being able to name a concrete thing L7 can do that L4 can't.

Q3. Round robin vs least connections: when does it matter?

They're testing: algorithm trade-offs.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** Round robin is fine when servers are identical and requests take similar time. When request duration varies a lot, round robin keeps sending new requests to a server stuck on slow ones, so its queue grows; least connections sends new work to the server with the fewest requests in progress and adapts automatically. Weighted variants handle servers of different sizes.
3
4**Counter-questions:**
5- *"What's the risk with least connections across many load balancers?"* → Each load balancer only sees its own counts, and they may all rush to the same "least busy" server. Picking two servers at random and choosing the less busy one avoids that herd effect.
6
7**Trap:** claiming one algorithm is always best.

Q4. How do health checks work, and what can go wrong?

They're testing: operational depth.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** The load balancer probes each server, usually an HTTP health endpoint, every few seconds, marks it down after a set number of failures in a row and back up after a set number of passes. Things go wrong when checks are too shallow (the process is up but can't reach the database), too heavy (the checks themselves add load), or all depend on one shared component, so one blip marks every server down at once. Timing is a trade-off between detecting failure quickly and flapping.
3
4**Counter-questions:**
5- *"Should the health check test the database?"* → Carefully. A readiness check can include critical dependencies, but if every server fails together on a short database blip, the load balancer has nothing left to send to. Many systems keep the check mostly local and let other alerts catch dependency failures.
6
7**Trap:** "the health check returns 200".

Q5. What are sticky sessions, and what's wrong with them?

They're testing: the stateless principle.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** Sticky sessions send all of a user's requests to the same server, using a cookie or a hash of their IP. They let servers keep per-user state in memory, but load becomes uneven, a dead server loses its users' sessions, and scaling in or deploying kicks users off. It's better to keep servers stateless with sessions in a shared store, and use stickiness only where a connection must stay on one server, like WebSockets.
3
4**Counter-questions:**
5- *"How would you remove a server that has sticky users?"* → Drain it: stop new sessions, let existing ones finish or move them, then remove it.
6
7**Trap:** recommending sticky sessions as the default.

Q6. What is SSL termination? Is it safe?

They're testing: security and trade-off awareness.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** The load balancer decrypts HTTPS so certificates live in one place and L7 features can read the request. Traffic from the load balancer to the servers is then plain HTTP unless we re-encrypt it. In a private network that may be acceptable for some, but many organisations require encryption inside too, so the load balancer opens new TLS connections to the servers, or uses passthrough at L4 and loses L7 features.
3
4**Counter-questions:**
5- *"What's the cost of re-encrypting?"* → More CPU and a handshake per connection to backends, which connection reuse largely hides.
6
7**Trap:** "terminating TLS means traffic is insecure", or the opposite, ignoring the internal hop.

Q7. The load balancer is a single point of failure. How do you fix it?

They're testing: redundancy at every layer.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** Run at least two. In an active-passive pair, they share a virtual IP and the standby takes over through a heartbeat protocol like VRRP. In active-active, several load balancers serve traffic, spread by DNS or anycast. Managed cloud load balancers are redundant across zones by design. And spread the servers behind them across availability zones too.
3
4**Counter-questions:**
5- *"What happens to in-flight connections during a failover?"* → They're usually dropped and clients reconnect, which is why clients need sensible retries (Chapter 29).
6
7**Trap:** forgetting that the load balancer itself can fail.

Q8. Forward proxy vs reverse proxy?

They're testing: precise vocabulary.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** A forward proxy acts for clients: they send traffic through it, and it can filter, cache, log and hide their addresses. A reverse proxy acts for servers: clients connect to it as if it were the server, and it forwards to the real servers, doing load balancing, TLS termination, caching and compression. Load balancers and API gateways are kinds of reverse proxy.
3
4**Counter-questions:**
5- *"Is a CDN a forward or reverse proxy?"* → A reverse proxy, acting for the website's servers, placed near users (Chapter 26).
6
7**Trap:** mixing up which side each one serves.

Q9. What does an API gateway do, and when would you not want one?

They're testing: knowing its value and its risks.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** It's a reverse proxy at the front of your APIs that handles shared concerns: authentication, rate limiting, routing to services, TLS, logging and metrics. It's most useful with many services and many clients. It adds a hop and becomes a critical shared component, and it turns into a bottleneck if teams put business logic in it. For a single small service, a plain load balancer may be all you need.
3
4**Counter-questions:**
5- *"Where do you check permissions, at the gateway or in the service?"* → Identity at the gateway; fine-grained permissions ("can this user see this order?") in the service, which knows the data.
6
7**Trap:** describing the gateway as the place for all logic.

Q10. How would you route users to the nearest region?

They're testing: global traffic basics.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** Use global load balancing to pick a region, then regional load balancers to pick a server. DNS-based geo or latency routing is simple but limited by caching and resolver location; anycast routes to the nearest location at the network level and fails over quickly. The real challenge is having the user's data available in that region, which needs replication.
3
4**Counter-questions:**
5- *"A region goes down. How fast do users move?"* → With anycast or a global load balancer, typically seconds; with DNS, up to the record's TTL (Chapter 4).
6
7**Trap:** ignoring where the data lives.
8
9---
10
11## Practice coverage
12
13Every section in this chapter is tested at least once.
14
15| Section | Tested by |
16|---|---|
17| 7.1 Why a load balancer | Level 5.1, Q1 |
18| 7.2 L4 vs L7 | Level 1A, Q2 |
19| 7.3 Algorithms | Level 1B, Level 2.3, Level 3, Level 4, Q3 |
20| 7.4 Health checks | Level 2.1, Level 2.2, Level 3, Level 5.3, Q4 |
21| 7.5 Sticky sessions | Level 1A.4, Level 4, Q5 |
22| 7.6 SSL termination | Level 5.2, Q6 |
23| 7.7 Redundant load balancers | Level 5.4, Q7 |
24| 7.8 Forward vs reverse proxy | Q8 |
25| 7.9 API gateway | Level 5.5, Q9 |
26| 7.10 Global load balancing | Q10 |
27
28---

7. Load Balancers, Reverse Proxies and API Gateways