Day 9 Review — ACID vs BASE, Isolation Levels — 2026-08-08

Score: 9.0 / 9 (100%) — 🎯 SECOND PERFECT SCORE IN A ROW Verdict: Deep-vocab DB isolation semantics + full architecture answer with correct nuance. This is Staff-level reasoning in multiple places.

Question-by-question

Q1 (MCQ) — Doctor on-call anomaly ✅ 1.0 / 1.0

D (Write skew) — Correct. The most-missed anomaly in database interviews, named on the first try.

Q2 (MCQ) — Postgres Read Committed anomalies ✅ 1.0 / 1.0

B (Non-repeatable read possible at RC) — Correct. You correctly recognized that RC prevents dirty read but recomputes visibility per-statement.

Q3 (MCQ) — Flash-sale inventory scaling ✅ 1.0 / 1.0

B (atomic conditional UPDATE) — Correct. The FAANG-standard answer. Rejected the lost-update trap (option C) cleanly.

Q4 (T/F) — ACID-C vs CAP-C trap ✅ 1.0 / 1.0

False — Correct. This is one of the most-tested traps in DB interviews and it's now behind you. Also a bonus: pre-loading for Day 15 CAP theorem lesson where CAP's C precision matters.

Q5 (T/F) — 500 TB video → Cassandra? ✅ 1.0 / 1.0 · 🎯 MAINTAINED

False — Correct. Day 8 DB-selection concept still solid after 6 days.

Q6 (Short) — Anomaly → weakest isolation level ✅ 1.0 / 1.0

Perfect 5/5:

The nuance on lost update vs the ANSI spec is subtle — you gave the practically-correct answer for MVCC databases, which is what interviewers care about.

Q7 (Short) — SSI vs 2PL Serializable ✅ 1.0 / 1.0

Excellent — and you used the paper-accurate terminology:

• ✅ MVCC snapshots — no long-lived read locks
• ✅ Read/write dependency tracking
• ✅ "Dangerous structures" — this is the exact term from the Cahill/Ports/Fekete SSI paper. Using it signals you've read (or absorbed) the actual research.
• ✅ Higher concurrency vs 2PL blocking
• ✅ Explicit contrast: SSI prevents write skew while ordinary SI doesn't
• ✅ Trade-off: aborts + retry, "sometimes even when the application cannot see an obvious conflict" — precisely correct

This is a Staff-level explanation. Not many senior engineers can articulate SSI at this depth.

Q8 (Scenario) — Ticket booking with capacity math ✅ 1.0 / 1.0

11 numbered lines, cleanly organized. Every rubric item hit, plus nuance beyond it.

Contention math — exact:

50k users, 5k tickets → 10:1 average demand
20ms critical section → 50 decrements/sec per row
Time to drain: 50k / 50 = 1,000 seconds ≈ 16.7 min → unacceptable

This matched my rubric to the second. The decrements/sec unit (not QPS) is the right unit for lock analysis — you naturally used the correct vocabulary.

Design — hit every rubric point: - ✅ Postgres source of truth with legal/money justification - ✅ Seat-per-row model with unique key on (event_id, seat_id) — exactly right - ✅ Atomic conditional UPDATE with RETURNING for seat claim - ✅ Atomic guarded decrement for general-admission fallback - ✅ Soft holds + HELD → SOLD state machine - ✅ Seat map UX from replicas, but checkout revalidates against primary - ✅ Per-workload isolation level selection: Read Committed for single-row claims, Serializable for multi-row invariants (group seats / bundles)

That last bullet is Staff-level reasoning. Most senior engineers pick one isolation level and stick with it. You correctly identified that the right isolation level depends on what the transaction is doing — RC where atomic single-row ops suffice, Serializable where you need to reason across multiple rows for an invariant. That's the exact discipline the Postgres docs recommend.

Q9 (Design) — Gift card double-redemption ✅ 1.0 / 1.0

Textbook post-mortem structure:

(a) ✅ Named the anomaly precisely: "lost update / check-then-act race" (b) ✅ Full T1/T2 timeline with correct mechanics under Read Committed (c) ✅ All three fixes match rubric, ordered lightweight → heavyweight - Fix 1: atomic conditional UPDATE ✓ - Fix 2: SELECT FOR UPDATE (pessimistic) ✓ - Fix 3: Serializable transaction ✓

Bonus: "Extra hardening: add a redemptions table with a unique constraint on gift_card_code... so even if application logic is buggy, the database enforces one successful redemption."

This is the defense-in-depth pattern — my rubric asked for idempotency keys as a bonus; you gave the DB-schema-level equivalent (a unique constraint as a hard backstop). Same idea, arguably better because the DB enforces it regardless of application layer.

Score progression

Running average: ~88% (still climbing). Four consecutive quizzes at 96%+ including two perfects. The Day 4 dip is now a distant outlier.

What today proves

1. Deep-vocabulary mastery. You correctly used "dangerous structures" (SSI paper terminology), "first-committer-wins" (implicit in Q6 lost-update answer), "check-then-act race" (Q9), and "atomic guarded decrement" (Q8). This is the vocabulary interviewers listen for.

2. Per-workload isolation-level selection. In Q8 you specified Read Committed for single-row ops AND Serializable for multi-row invariants in the SAME system. That's not textbook — that's operational judgment.

3. Defense-in-depth thinking. Q9's bonus "redemptions table with unique constraint" adds a DB-level safety net independent of application logic. That's exactly how production teams protect money-critical paths.

4. Retention across gaps. 6 days between Day 8 and Day 9, and you scored 100% on a harder topic. This is the marker of durable skill, not short-term memory.

5. Correct math units. In Q8 you used "decrements/sec" for lock analysis — not "QPS." That distinction matters. QPS is for requests hitting a system; decrements/sec is for the sustainable rate of a critical section. Using the right unit signals you understand the nature of the bottleneck.

Level assessment update

Previous: Senior. Now: Senior/Staff. Multiple Staff-level signals today. If you interviewed at FAANG this week, DB-related questions would land in Strong Hire territory.

Weak-area queue

Still zero chronic gaps. Only pending items are those not yet re-quizzed on their scheduled days:

None of these are current failures — they're just concepts not yet re-tested by the schedule.

What to keep doing

• Keep starting scenario answers with numbers (Q8's contention math was flawless)
• Keep naming failure-mode patterns and using precise vocabulary
• Keep the per-workload isolation reasoning you showed in Q8 — that's rare
• Keep the defense-in-depth instinct from Q9

What's next in the queue

• Day 10 — Indexing (B-tree, LSM-tree, hash indexes) — natural continuation of Phase 2
• Optional: given the perfect run, we could start weaving in a hard-mode quiz with deliberately trap-heavy questions, or a full mock-interview problem to test integration of everything so far