Day 1 Review — Client-Server, HTTP, DNS — 2026-07-22

Score: 7.5 / 9 (83%) Verdict: Strong. Big improvement over the diagnostic (71% → 83%). All MCQ + True/False answers correct. Reasoning depth on the free-text is where you can still level up.

Question-by-question

Q1 (MCQ) — HTTP statelessness ✅ 1.0 / 1.0

Your answer: B — Correct. Statelessness → any server serves any request → horizontal scaling. This is one of the most important consequences to have on the tip of your tongue in interviews.

Q2 (MCQ) — Idempotency ✅ 1.0 / 1.0

Your answer: C (GET, PUT, DELETE) — Correct. Retention tip: idempotency matters at the network layer because of retries. If a client doesn't get a response, it doesn't know if the server processed the request. For PUT/DELETE, retrying is safe; for POST, retrying can duplicate. That's why real APIs add an Idempotency-Key header for POSTs that must not double-fire (Stripe, AWS APIs do this).

Q3 (MCQ) — DNS TTL ✅ 1.0 / 1.0

Your answer: B — Correct. Up to ~1 hour (or a bit more, because some misbehaving resolvers ignore TTL).

Q4 (T/F) — PUT idempotency ✅ 1.0 / 1.0

Your answer: True — Correct. Small precision note: your wording said "PUT is idempotent it will make the same resource multiple times with the same state." The cleaner framing is "repeated identical PUT calls leave the resource in the same end state as one call." The verb "make" implies creation each time — PUT actually replaces, which is what makes it idempotent (multiple replaces with the same body = same final value).

Q5 (T/F) — Symmetric encryption after handshake ⚠️ 0.8 / 1.0

Your answer: True — Correct answer. But your justification missed the point of the question.

You said: "the client and server have the same key which they use to share information." That's true but incomplete. The question specifically distinguished symmetric vs asymmetric. The full answer should be:

True. The TLS handshake uses asymmetric crypto (RSA / ECDHE) only to exchange or derive a shared secret. From that point on, both sides use symmetric crypto (AES-GCM, ChaCha20). Reason: symmetric is ~1000× faster than asymmetric on the same hardware — impractical to use asymmetric for every byte of an HTTPS response.

Getting the "why" of symmetric-vs-asymmetric down is a common FAANG probe when they ask about HTTPS cost.

Q6 (Short) — Status codes ✅ 4.7 / 5.0

All 5 codes correct — excellent. Two small precision improvements:

Q7 (Short) — Two login mechanisms ⚠️ 0.5 / 1.0

You correctly identified the two most common mechanisms (server sessions + JWT), but the trade-offs are muddled or wrong.

Your trade-off for session cookies:

"if there are multiple servers then in each server we have that cookie is there because the server won't know which server will process the request."

This is close to the real trade-off but scrambled. The client sends the cookie on every request; the server doesn't need to "have" the cookie. The actual issue: the session data the cookie references lives on the server side, and if it's in-process memory, each server has its own copy — you need a shared session store (Redis) so any server can look up the session. Precise phrasing:

Trade-off: requires a centralized session store (Redis, DB); adds a network hop per request; but revoking a session is trivial (delete the key).

Your trade-off for JWT:

"how after that 7 days expiry be set so that any request comes after 7 days must fail."

That's not a trade-off — that's how it works (JWT has an exp claim; server checks it). The real JWT trade-offs are:

Trade-offs of JWT: - Hard to revoke before natural expiry. Once issued and signed, it's valid until exp unless you maintain a server-side blocklist (which defeats the "stateless" appeal). - Storage in localStorage is XSS-vulnerable. If any script on your page gets compromised, the token is stolen. HttpOnly cookies are safer. - Bigger requests (JWT is a few hundred bytes on every request). - Key rotation is painful — you have to keep old signing keys around until all tokens issued with them expire.

A good rule-of-thumb answer: - Session cookies: best when you need easy revocation, small tokens, and you already run Redis anyway. - JWT: best when you have distributed services that can't share a session store (microservices) and you're OK with delayed revocation.

Q8 (Scenario) — Sydney slowness ⚠️ 0.7 / 1.0

You got the strongest hypothesis (TCP + TLS = ~3 RTT ≈ ~600 ms cold to Virginia) and the best mitigation (CDN edge in Sydney). But the other two hypotheses were a bit vague:

• "check for the cache is working" — too vague. Which cache? Browser? CDN (there isn't one yet)? App-level?
• "check the DB queries" — DB latency is the same for a US user. If the DB were slow, US users would also complain. Sydney's problem is almost certainly network latency to us-east-1, not the DB.

A tighter answer would list hypotheses tied to the specific 8-step flow, all amplified by ~200ms RTT:

1. DNS cold lookup — ~100 ms if the record isn't cached at the local ISP.
2. TCP handshake — 1 RTT (~200 ms).
3. TLS handshake — 1–2 RTT (~200–400 ms for TLS 1.3 / 1.2).
4. TCP slow start — with cold connections, initial CWND is small, so large payloads take multiple RTTs to fully arrive.
5. HTTP/1.1 head-of-line blocking — if you're on HTTP/1.1, browsers cap at 6 connections per domain, so each round-trip serializes.
6. Payload size × RTT — even a 200 KB page over ~200 ms RTT can add 500+ ms if not compressed and streamed well.

Cheap mitigations (before adding Sydney servers): - Put a CDN in front (CloudFront/Fastly edge in Sydney) — biggest win, minutes to enable. ✓ (you got this) - Enable HTTP/2 or HTTP/3 — eliminates head-of-line blocking, dramatic win over HTTP/1.1. - Enable compression (gzip / brotli). - Enable TLS session resumption — turns 2 RTT TLS 1.2 handshake into 1 RTT on repeat visits. - Aggressive Cache-Control on static assets — 90% of a page load is often static. - Measure first with Chrome DevTools waterfall to see which step is actually slow — don't optimize blindly.

The habit to build: for "why is X slow" always walk through the 8-step flow.

Q9 (Mini design) — DNS failover ⚠️ 0.6 / 1.0

Parts 1 and 2 were correct: ~1 hour, and DNS resolver caching is why. Part 3 has the right direction but the mechanism is imprecise:

Your architectural fix:

"put a load balancer in front... first that load balancer check if that domain is healthy or not and it invalidates it and if it found that one is not healthy it will point to the new ip mapped to that domain."

A load balancer doesn't check "if a domain is healthy" — it checks backend servers. The clean model:

Client -> DNS resolves once to LB's stable IP -> LB routes traffic to healthy backend

                                        LB
                                        /  \
                                       /    \
                              backend-1   backend-2
                              (primary)   (standby)

• Clients continue using the LB's IP (which doesn't change).
• The LB does health checks (e.g. HTTP GET to /health every few seconds) on each backend.
• When primary fails, the LB stops sending traffic there and routes to standby — within seconds, no DNS involved.

Additional architectural options a strong candidate would mention:

• Anycast IP — one IP announced from many regions (Cloudflare/Google style). BGP routing takes users to the nearest healthy location. Failover is near-instant across continents.
• Low DNS TTL for records that might change — set TTL to 60s instead of 1 hour if you must rely on DNS-based failover. Trade-off: more DNS queries.
• Health-checked DNS (Route 53) — DNS returns only healthy IPs, but you're still bounded by TTL.
• Client-side failover — clients try IP A, on failure try IP B (rare for browsers, common in mobile apps and service-to-service).

The key insight to remember: DNS is for name resolution, not for fast failover. Any time you need failover in seconds, put a component (LB, Anycast) in front that can decide traffic routing at request time, not at DNS-cache-expiry time.

Summary

Auto-graded score: 5/5 (100%) — perfect on MCQ + True/False. Free-text score: 2.5/4 (63%) — right ideas, imprecise articulation. Overall: 7.5/9 (83%)

Progress vs diagnostic

Top 3 things to fix

1. JWT vs session cookie trade-offs — memorize the real trade-offs (revocation difficulty for JWT, session-store dependency for cookies). Free interview points.
2. When articulating "why symmetric" or similar — always contrast: "X vs Y, we pick X because [speed / durability / whatever]." The contrast is the answer.
3. When asked "why is X slow", walk the request flow — don't jump straight to "DB queries" if the user is on the other side of the planet. Latency has an anatomy; know it.

Weak-area queue update

You're moving fast. Day 2 is next: Latency, Throughput, and back-of-envelope numbers — perfect follow-up to today's "latency anatomy" gap.