Day 8 Review — SQL vs NoSQL — 2026-08-02

Score: 9.0 / 9 (100%) — 🎯 PERFECT SCORE Verdict: The last chronic gap (capacity math) closed on the exact quiz that graded for it. Every spaced-repetition weak area is now resolved. This is a level-transition moment.

Question-by-question

Q1 (MCQ) — URL shortener storage ✅ 1.0 / 1.0

C (Redis / DynamoDB KV) — Correct. Matched DB to access pattern (pure key→value), not to scale alone. That reasoning discipline is what separates senior from junior.

Q2 (MCQ) — Fraud detection graph traversal ✅ 1.0 / 1.0

B (Graph DB) — Correct. Recognized that multi-hop relationship traversals are O(edges), not O(rows).

Q3 (MCQ) — IoT sensor 10M devices × 1/s ✅ 1.0 / 1.0

C (TSDB or Cassandra with time-partitioned key) — Correct. Implicitly recognized that Postgres tops out ~50k writes/s and this needs 10M writes/s.

Q4 (T/F) — "Postgres caps at 5k QPS" myth ✅ 1.0 / 1.0

False — Correct. Trap recognized. A senior candidate never says "SQL doesn't scale" without numbers behind it.

Q5 (T/F) — L1 cache trade-off maintenance ✅ 1.0 / 1.0 · 🎯 MAINTAINED

True — Correct. Day 6 Q2 concept still solid.

Q6 (Short) — Best-fit DB × 5 ✅ 1.0 / 1.0

Perfect 5/5:

All correct with textbook DB → workload alignment.

Q7 (Short) — Cassandra vs Postgres write throughput ✅ 1.0 / 1.0

Excellent answer with all the key mechanics: - ✅ LSM-tree with commit log + memtable → SSTables - ✅ Sequential vs random I/O contrast explicitly named - ✅ Postgres B-tree + WAL + index maintenance + transactional overhead - ✅ Bonus: distributed shared-nothing scaling advantage - ✅ Trade-off: eventual consistency + read amplification (multiple SSTables + compaction background I/O)

This is graduate-level storage-engine reasoning. If you said this in an interview, the interviewer would immediately calibrate you upward.

Q8 (Scenario) — Chat storage design ✅ 1.0 / 1.0 · 🎯 CHRONIC GAP CLOSED

Capacity math — present, correct, and thorough:

Daily messages = 60M × 40 = 2.4B/day
Avg write QPS = 27.8k writes/s
Peak (5×)     = 139k writes/s
Storage/day   = 1.2 TB
Storage/year  = 438 TB
+ 3× replication → ~1 PB+/year

Every number I wanted, plus one I didn't: the 3× replication multiplier is exactly the kind of production-realistic adjustment that shows you're thinking beyond the surface. That single line is the difference between a "textbook" candidate and someone who's operated systems.

Design decisions — all correct, all grounded in the numbers: - ✅ Cassandra/ScyllaDB primary — justified explicitly against Postgres's ~50k write ceiling - ✅ Partition key conversation_id, clustering key message_time DESC - ✅ Query pattern maps to single-partition sequential read - ✅ Hot-partition mitigation with time bucketing (conversation_id, day/month) — exactly the right defensive design - ✅ Tier old messages to S3 for cheap forever retention — this is the polyglot thinking senior engineers reach for and juniors don't - ✅ Two alternatives explicitly rejected with numeric reasoning (Postgres, Redis)

This is a textbook FAANG-level scenario answer. Numbers → constraints → decision → alternatives → mitigation. That's the structure. You now own it.

Q9 (Design) — OLTP + event ingestion post-mortem ✅ 1.0 / 1.0

Excellent, senior-level answer: - ✅ Named the architectural mistake precisely: "mixing high-volume activity-event ingestion with the OLTP user database" - ✅ Enumerated the specific resource contention vectors: CPU, I/O, buffer cache, storage bandwidth, WAL generation, autovacuum pressure - ✅ Correctly explained why replicas won't fix it: writes still hit primary; replication overhead can worsen the situation - ✅ Bonus insight: "additional replicas can increase replication overhead and operational complexity while the primary remains saturated" - ✅ Full migration path with 5 concrete steps: dual-write → validate consumers → backfill → switch reads → drop old tables - ✅ Named polyglot persistence as the concept - ✅ Closing summary explaining the why of the split

This is what a real post-mortem doc looks like. Root cause + why easy fixes fail + specific fix + migration + result.

Score progression

Running average: ~86% (climbing). Three consecutive quizzes at 96%+ including one perfect.

What today proves

1. The capacity-math gap is closed. The reason: I flagged Q8 as capacity-math-required, and you delivered more math than I asked for (adding the 3× replication multiplier). That's the exact behavior pattern that resolves chronic weaknesses — direct pressure + deliberate practice → new default habit.

2. All spaced-repetition weak areas are now resolved. Zero remaining chronic gaps. Look at what's behind you:

3. Your architecture answers are now genuinely senior/staff-level. Q8 today would earn Strong Hire signal at any FAANG. It has: capacity math first → workload characterization → matched DB with numerical justification → sharding key + clustering key → hot-partition mitigation → cost-tiered storage → alternatives explicitly rejected.

4. You've completed all of Phase 1 (Foundations). Days 1-7 (Foundations) + Day 8 (bridge to Data & Storage) are done. You're at the entrance to Phase 2.

Level assessment update

Previous: Intermediate (upper) approaching Senior. Now: Senior. With 2-3 more topic weeks at this quality, Staff-approaching.

The remaining Medium-severity items in the queue (slow-start, CAP theorem precision, retry amp phrasing) are all "hasn't been re-quizzed yet" rather than "keeps failing." Very different category from chronic gaps.

Weak-area queue — CLEAN

None of the pending items are chronic failures. They're just topics not yet revisited by the spaced-repetition schedule.

What to keep doing

• Always start scenario answers with numbers. You just proved you can. Don't lose that habit.
• Keep naming failure-mode patterns ("thundering herd," "cold cache stampede after content refresh," "OLTP + event ingestion coupling"). Naming = pattern recognition = senior signal.
• Keep explicitly rejecting alternatives in scenario answers. "I'd reject X because…" is a Strong Hire pattern.
• Keep referencing production-realistic details (replication multipliers, cost per QPS, real-company examples). You now do this naturally.