Diagnostic Review — 2026-07-20

Score: 7.1 / 10 (71%) Assessed level: Late Beginner → Early Intermediate

You have strong intuition (all 3 MCQs correct, latency ranking perfect) but reasoning depth is inconsistent. This is exactly the transition zone the curriculum targets — expect fast gains.

Question-by-question

Q1 — L7 vs L4 Load Balancer ✅ 1.0 / 1.0

Your answer: b — Correct. L7 (HTTP-aware) can inspect URL paths, headers, cookies, and route accordingly. L4 (TCP/UDP-level) only sees IP + port, so it's faster but "dumber". Common L7 examples: NGINX, HAProxy in http-mode, AWS ALB. L4: AWS NLB, HAProxy in tcp-mode.

Q2 — Why cache? ✅ 1.0 / 1.0

Your answer: b — Correct. Caches reduce read latency and take load off the DB. They do not improve durability (caches are usually volatile) or atomicity.

Q3 — When NoSQL? ✅ 1.0 / 1.0

Your answer: c — Correct. The classic NoSQL fit: high volume, flexible/semi-structured schema, horizontal scale, no complex joins. (a), (b), (d) all describe SQL strengths.

Q4 — CAP theorem ⚠️ 0.5 / 1.0 (right answer, wrong reasoning)

Your answer: True. Correct. But your reasoning is off: you said "without network partition the resources can't share information." That's the opposite — with a partition, they can't communicate.

Correct reasoning:

During a network partition, two sides of the partition can't sync. You must choose: - Reject writes to keep consistency (sacrifice Availability — CP system, e.g. HBase, Zookeeper) - Accept writes on both sides and reconcile later (sacrifice Consistency — AP system, e.g. Cassandra, DynamoDB default)

There is no third option because you literally can't atomically update nodes that can't talk to each other.

Also — nuance FAANG interviewers love: CAP applies only during a partition. When the network is healthy, systems can be both consistent and available. That's why the modern refinement is PACELC: during Partition → A vs C; Else → Latency vs Consistency.

Q5 — HTTP stateful? ❌ 0.0 / 1.0 (this one is important — flagged for revisit)

Your answer: True. ❌ The correct answer is False.

HTTP is stateless by design. Each request is independent — the server does not remember anything about the client between requests. This is a foundational property.

Statelessness has nothing to do with security. It's about the protocol itself: - Every HTTP request is self-contained: method, URL, headers, body. - The server processes it and forgets. Next request from you? The server has no idea you were the same person.

Then how do apps "remember" you (login, cart, etc.)? By explicitly adding state on top of HTTP: - Cookies — server sends Set-Cookie, browser echoes it in every subsequent request - Session IDs — cookie contains an opaque ID; server looks up your session in a store (Redis, DB) - JWT / Bearer tokens — self-contained signed tokens in the Authorization header - URL params — session state encoded in the URL

Why does statelessness matter for system design? - Any server can handle any request → trivial horizontal scaling behind a load balancer - Failure recovery is easy — no server-local state to lose - Downside — every request must carry its own context (heavier requests, session lookups)

This is a must-know FAANG fact. We'll drill it in Day 1.

Q6 — Latency ranking ✅ 1.0 / 1.0

Your answer: 3 > 4 > 2 > 1 > 5 — Perfect.

For reference (Jeff Dean's "numbers everyone should know"):

Memorize this table — it justifies half the trade-offs you'll make in a design interview.

Q7 — DNS ⚠️ 0.5 / 1.0 (concept right, flow wrong)

Your answer: mostly correct at the concept level (DNS maps names → IPs), but the flow is muddled:

Corrections: 1. DNS = Domain Name System (not "Resolver" — the resolver is one component of the system). 2. DNS resolution happens before any HTTP request or CDN routing — the browser needs an IP to open a TCP connection in the first place. CloudFront doesn't do DNS lookups for you; it's the result you might get back.

Actual flow when you type www.google.com:

1. Browser cache — checked first (recent lookups cached for TTL).
2. OS cache — /etc/hosts and OS-level cache checked.
3. Recursive resolver (usually your ISP or 8.8.8.8 / 1.1.1.1) — the browser sends a DNS query here.
4. Resolver walks the DNS hierarchy: - Asks a root nameserver → "who handles .com?" - Asks the TLD nameserver (.com) → "who handles google.com?" - Asks google.com's authoritative nameserver → "what's the IP for www.google.com?"
5. Resolver returns the IP to your browser.
6. Browser opens a TCP connection to that IP (often a CDN edge IP for Google), then sends HTTPS.

Interview-worthy nuance: DNS also enables load balancing (return different IPs per user via geo-DNS, weighted round-robin) and failover.

Q8 — Vertical vs Horizontal scaling ✅ 1.0 / 1.0

Great answer. Small additions FAANG interviewers like:

Your pros/cons captured the essentials. Bonus if you had said "vertical hits a ceiling and cost becomes super-linear (a 128-core box costs way more than 4× a 32-core box)."

Q9 — URL shortener DB choice ⚠️ 0.6 / 1.0

Your answer: NoSQL. Reasonable choice, but the reasoning is shaky.

What was off: "SQL requires a structured query which takes time" isn't accurate. A Postgres primary-key lookup (SELECT long_url FROM urls WHERE short_code = ?) with a B-tree index is extremely fast — sub-millisecond on a warm cache. SQL is not slow because of "structured queries."

Better reasoning (what FAANG expects): 1. Access pattern is pure key-value — one lookup: short_code → long_url. No joins, no complex queries. Wasting SQL's relational power. 2. Scale: 100M new records/month = ~1.2B/year. A single Postgres node struggles beyond a few TB and one machine. NoSQL (DynamoDB, Cassandra) shards horizontally out of the box. 3. Global < 50 ms reads: needs multi-region reads. DynamoDB Global Tables / Cassandra multi-DC give this natively. Postgres multi-region is painful. 4. Reads dominate (10:1) — put a cache (Redis / Memcached) in front and a CDN for hot short codes. This actually matters more than SQL vs NoSQL.

Note: both answers can be defended in an interview. What separates candidates is the reasoning, not the choice. "I'd pick Postgres and add read replicas + Redis" is also acceptable if defended well.

Q10 — Rate limiter ⚠️ 0.5 / 1.0

Your answer got the structure right (server-side counter, 429 response, token bucket) but has one clear misstep and one big miss:

What you got right: - Counter server-side, not client-side ✓ - HTTP 429 Too Many Requests ✓ - Token bucket is a valid algorithm choice ✓

The problem with your "problem":

"attacker throws 1000 req/min → legitimate requests get 429."

If the rate limit is per API key, and the attacker is using their own key, then only their requests get 429'd — that's the intended behavior, not a bug. Other users are unaffected. So this isn't a real problem.

Bigger issues you missed (this is the FAANG angle): 1. Distributed state. "Server-side counter" is vague. If you have 10 app servers behind a load balancer, an in-memory counter on each server means the attacker can send 100 req/min to each server = 1000 total. Real answer: centralize the counter in Redis (using INCR + EXPIRE, or a Lua script for atomicity). 2. Race conditions. Naïve check-then-increment isn't atomic. Use atomic ops (INCR, Redis Lua scripts) or CAS. 3. Time-window boundaries (fixed window flaw). With a fixed 1-minute window, a caller can send 100 requests at 12:00:59 and another 100 at 12:01:00 — 200 in 2 seconds. Fixes: sliding window log, sliding window counter, or token bucket. 4. Return metadata: also send headers X-RateLimit-Limit, X-RateLimit-Remaining, Retry-After. 5. Fail-open vs fail-closed when Redis is down: usually fail-open (allow) for availability.

We'll design a rate limiter properly on Day 23 and Day 27.

Overall assessment

Strengths: - Latency intuition (Q6) — perfect - Recognizing L7 vs L4, cache purpose, NoSQL fit — clean - Vertical vs horizontal scaling explained cleanly - General instincts are correct

Weaknesses to attack: | Weak area | Where it showed | Day it's addressed | |----------------------------------|-----------------|---------------------------| | HTTP fundamentals (statelessness)| Q5 (wrong) | Day 1 (today) | | DNS resolution flow | Q7 | Day 1 (today) | | CAP theorem — precise reasoning | Q4 | Day 15 | | Reasoning depth on DB trade-offs | Q9 | Days 8–14 | | Distributed state (rate limiter) | Q10 | Days 17, 23, 27 |

Level calibration decision: Curriculum will proceed as planned (Day 1 → Day 30). Day 1 is perfect because it directly hits your two weakest areas (HTTP + DNS). No skip.

Spaced repetition queue: Q5 (HTTP stateless), Q4 (CAP reasoning), Q10 (rate limiter distributed state) will be re-quizzed on Day 4 and Day 11.