# Mission: Backend Depth

## Why
Self-imposed deadline to close the gap between "can build backend features" and "can explain why the underlying machinery behaves the way it does under load, concurrency, and failure." Driven by job hunting for backend/infra roles — this gap is what gets exposed in system design and debugging interview rounds, and what makes production incidents take longer to resolve than they should.

## Success looks like
- Diagnoses a live production latency/error issue by reasoning from the *shape* of the symptom (spike vs. slow bleed, correlated vs. random) to a candidate root-cause class, before guessing or reaching for a stress test.
- Reads an `EXPLAIN ANALYZE` plan, explains why Postgres chose the plan it did, and knows when a composite index changes the work done (not just "add an index").
- Explains transaction isolation levels (starting with READ COMMITTED) well enough to spot check-then-act races and lost-update bugs in real code, and fix them at the SQL/schema level, not just with app-side locks.
- Explains cache invalidation tradeoffs (stampede, TTL, staleness) and picks the right technique for a given traffic scenario.
- Reasons about system design under partial failure (timeouts, retries, backpressure, network partitions) at an interview-appropriate depth.

## Constraints
- Self-imposed deadline (ultimatum) — job-driven, so pace matters. Prioritize depth-per-hour over breadth.
- Prefers being tested with concrete, realistic scenarios over abstract lecture — assessment showed this surfaces real gaps faster than "do you know X" questions.
- Curriculum order agreed: PostgreSQL internals/indexing → networking → OS/processes/threads → Python concurrency/runtime → distributed systems/failure models.

## Out of scope
- Learning a new framework or programming language — explicitly ruled out; would add another abstraction layer on top of the same gaps rather than closing them.