# Baseline assessment: solid at building, fuzzy under concurrency/failure

Initial diagnostic (before any lessons) tested three areas with concrete scenarios instead of abstract questions, confirming a consistent pattern: strong at "how do I build this" but no working model for "why does the machinery behave this way under concurrency/failure."

## Evidence

- **Debugging (latency spike, restart-fixes-it pattern):** Defaulted to "check logs" + "stress test in sandbox" — no specific tool/metric named, no reasoning from symptom shape (slow bleed vs. sudden spike) to a root-cause class. Did not know that "degrades over hours, restart clears it" is the signature of an accumulating leak (connection pool, memory/GC, FD/thread) rather than a load spike.
- **Transactions (concurrent balance transfer under READ COMMITTED):** Could not reason through whether two concurrent app-level check-then-write transfers could corrupt a balance. Did not know the check-then-act race exists under READ COMMITTED, or that the fix is an atomic conditional `UPDATE ... WHERE balance >= X` rather than an app-side lock.
- **Caching (500 concurrent requests on one expired key):** Did not know the term "cache stampede" / "thundering herd," or any of the standard fixes (single-flight/mutex-per-key, probabilistic early expiration, stale-while-revalidate).

## Implications

- This rules out "framework/language surface learning" as the next step — confirmed original diagnosis, not the "false competence" read. The actual gap is one level down: DB internals, concurrency correctness, OS/network fundamentals.
- Sets the floor for lesson design: start from zero on these specific mechanisms (composite indexes, isolation levels, cache stampede), don't assume vocabulary — even common jargon ("READ COMMITTED") needs a plain-language translation on first exposure.
- Confirms the curriculum order in [[MISSION.md]]: PostgreSQL internals/indexing first, since it's both the most concrete of the weak areas and ties directly to daily backend work.