Day 4 Review — Load Balancers — 2026-07-24

Score: 5.95 / 9 (66%) Verdict: Regression day — but a highly diagnostic one. The MCQs and Q6 mapping were nearly perfect. The damage came from two True/False traps (Q4, Q5) and a partial answer on Q7 (JWT vs sessions). One of the T/Fs is a regression on a Day 2 concept you originally got right — spaced repetition doing its job by catching that gap.

Don't let the score alarm you: after 3 days of stacking 83–90%, small dips are normal. What matters is which concepts leaked, not the point count.

Question-by-question

Q1 (MCQ) — Modern service-mesh algorithm ✅ 1.0 / 1.0

C (P2C) — Correct. Envoy, Finagle, gRPC libs all default to Power of Two Random Choices. Knowing this exists is a real interview differentiator.

Q2 (MCQ) — Cascading health-check failure ✅ 1.0 / 1.0

B — Correct. The subtle trap most beginners miss. Shared downstreams in /healthz mean one downstream blip → all backends fail health check → LB removes everything → total outage. Rule: /healthz checks local readiness only.

Q3 (MCQ) — When sticky sessions are justified ✅ 1.0 / 1.0

B (WebSocket chat) — Correct. Connections inherently pin to a backend for their lifetime; stickiness is natural for this workload. Everywhere else, prefer stateless.

Q4 (T/F) — Slow-start with least-connections ❌ 0.0 / 1.0 ← nuance trap

Your answer: True. Correct: False.

The intuition trap:

"Least connections routes to the backend with fewest active connections. So a cold backend (0 connections) will handle the load fine."

The reality:

A cold backend with 0 active connections is exactly what least-connections identifies as the most attractive target. It will get slammed with the next N requests until its connection count catches up — but its caches are cold, its JIT hasn't warmed, its DB connection pool is empty. It'll be slow and errors will spike.

Slow-start / connection ramp-up applies with every algorithm (round robin, least connections, P2C, hash-based). It's a separate concern: give a fresh backend 1% → 5% → 20% → 100% of its fair share over 30–60 s. Envoy, NGINX, AWS ALB all support this.

Mental model: "Least connections" solves the busy-backend problem, not the cold-backend problem.

Q5 (T/F) — Bandwidth halves latency? ❌ 0.0 / 1.0 ← 🚨 REGRESSION from Day 2

Your answer: True. Correct: False.

This is the same concept as Day 2 Q4 where you answered False correctly:

(Day 2 Q4) "Adding more bandwidth to a network link will reduce the round-trip latency of a small request over that link." → You: False ✓

Today you answered True to essentially the same question flipped. That's a genuine regression, not a careless click — the concept hadn't consolidated.

Lock it in — this is a memorization prompt:

Bandwidth ≠ latency. They are orthogonal. - Bandwidth = pipe width → bytes per second → helps big transfers - Latency = round-trip time → bounded by physics (speed of light through fiber) and equipment delays - Doubling bandwidth does not halve latency. A single small packet takes the same time on a 1 Gbps link and a 10 Gbps link if the distance is the same.

Say it out loud twice: "Bandwidth is not latency. Bandwidth is not latency."

This is a lesson to trust: spaced repetition works. The gap surfaced in a low-stakes quiz today rather than a high-stakes interview next month. Now we fix it. I'm scheduling this to re-appear on Days 7 and 11.

Q6 (Short) — 5 algorithm mappings ✅ 1.0 / 1.0

All 5 correct: 1. Stateless uniform API → Round Robin ✓ 2. WebSocket long-lived → Least Connections ✓ 3. Distributed cache key locality → Consistent Hash ✓ 4. Canary 5% → Weighted Round Robin ✓ 5. gRPC service mesh → P2C ✓

Perfect. Your algorithm-choice intuition is fully in place.

Q7 (Short) — JWT vs sessions (spaced repetition from Day 1) ⚠️ 0.5 / 1.0

Your answer:

"The core difference is where the user's logged-in state is stored: server-side session cookies hold a reference key while the actual data lives in a backend database, whereas JWT bearer tokens are self-contained data packages held entirely by the client."

This is a correct description of the mechanism. It's a significant improvement over your Day 1 answer, which had the concepts scrambled. Progress: real.

But the question specifically asked for the BIGGEST TRADE-OFFS — one strength + one weakness each. You gave a differentiation, not trade-offs.

The FAANG-clean answer looks like this:

Session cookies (opaque ID + server-side store): - Strength: easy revocation — deleting the session-store row instantly logs the user out on all devices. - Weakness: requires a shared, low-latency session store (Redis, DB) — adds a network hop per request and becomes a scaling dependency.

JWT bearer tokens (self-contained, signed): - Strength: stateless verification — any service can validate the token by signature alone, no store lookup, easy across microservices. - Weakness: hard to revoke before expiry — you can't invalidate a specific token without maintaining a blocklist (which defeats the "stateless" appeal). Also XSS-vulnerable if stored in localStorage.

Bonus one-liner to memorize: "Sessions are stateful and easy to revoke; JWTs are stateless and hard to revoke."

This same concept will re-quiz on Day 25 (Auth deep dive). I want to see the trade-off framing next time.

Q8 (Scenario) — Multi-region LB hierarchy ✅ 0.75 / 1.0

Solid. Hit all four required components: - ✅ Latency-based DNS (Route 53) for global routing to eu-west - ✅ ALB for regional LB - ✅ Cross-AZ distribution - ✅ TLS termination at regional LB

Two things to add for a stronger answer:

1. Mention Anycast as an alternative to DNS-based global routing. DNS routing has TTL issues (Day 1); Anycast IP handles global routing at the network layer — traffic goes to the nearest healthy cluster in seconds, without waiting for DNS caches to expire. FAANG interviewers love this add.

2. East-west (service-to-service) LB inside the region. You mentioned the north-south path (user → region → AZ → app) beautifully, but a real design also has internal LBs — usually an Envoy sidecar per pod / service mesh. Mentioning this shows you understand modern microservice architecture.

3. Minor: your HA answer was thin ("LBs scale automatically, span AZs"). Precise phrasing:

   "Cloud-managed L7 LB (ALB/GCP LB) runs multi-AZ under the hood — the control plane and data plane are fault-tolerant across zones. We get a stable DNS name; the provider handles failover in seconds. If we ran it ourselves, we'd use active-passive VRRP with a floating IP, or active-active with Anycast."

Q9 (Design) — Retry amplification post-mortem ✅ 0.7 / 1.0

Root cause diagnosis: excellent. You correctly identified: - ✅ Cascading retry amplification across both layers - ✅ Client SDK 3× × gateway 3× compounding - ✅ Connection storm + lock contention - ✅ Delayed recovery from back-pressure loop

One arithmetic slip: you wrote "up to 16x". For the described setup (3 client retries × 3 gateway retries), the ceiling is 3 × 3 = 9×, not 16×. Minor but worth being tight — FAANG interviewers do notice unit/arithmetic sloppiness.

Fixes: you got one of the three biggest, and missed the most important one.

The one-liner fix framing to use next time:

"Retries at one layer only, guarded by a circuit breaker, capped by a retry budget, bounded by a request deadline."

That's the four-legged stool of resilience.

Summary

Score progression

Don't panic. Look at the pattern: - All 3 MCQs correct — your recognition is sharp. - Q6 perfect — your algorithm-choice muscle is trained. - Both misses were T/F traps designed to catch shallow reasoning — high-signal for what to lock in. - The regression on Q5 is proof spaced repetition is working — it caught the gap early.

Top 3 things to lock in tonight

1. "Bandwidth is not latency." Say it twice out loud. Pinch yourself when you're about to answer "True" to any question of the form "more bandwidth → less latency." This will be tested again on Day 7 and Day 11.

2. Slow-start applies with every algorithm. Least-connections doesn't solve cold-start; it causes cold-start (0 connections = most attractive target). Slow-start is a separate ramp mechanism.

3. JWT vs sessions — the four-word cheat: "stateful & revocable vs. stateless & un-revocable." - Sessions: stateful (needs store), easy revoke (delete row). - JWT: stateless (no store), hard to revoke (need blocklist which negates the point).

Bonus: memorize the four-legged retry stool

"Retries at one layer only, guarded by a circuit breaker, capped by a retry budget, bounded by a deadline."

If you can drop that sentence in a resilience discussion, you sound senior. Bonus if you add: "and downstream retries respect the caller's remaining deadline via deadline propagation."

Weak-area queue update