Content audit
Discovery and instructional diagnosis
The inventory recursively covers both requested trees: 30 component files, 15 loop primitives, about 495,000 words, and 530 fenced assets. No separate image or executable file occurs within those trees. Examples, diagrams, formulas, exercises, and references are embedded in Markdown. SOURCE_INVENTORY records their locations and original hashes.
The largest overlap is storage durability/LSM, leases, rate limiting, caching, sharding, queues, CDC, replication, resilience, transactions, and regional recovery. Unique component material includes filters, consensus, IDs, gossip, networking, identity, retrieval, and bot defenses. Unique loop depth includes ambiguous outcomes, stream restoration, roll-ups, and long failure/recovery traces.
The loop primitives already use problem-first narrative and supported answer reveals; preserve that teaching idea. Their length and repeated recaps make them better reference chapters than single learning sessions. Components frequently name the solution before a learner has encountered the problem, and repeat identical routing/cloud/runbook scaffolds even when it does not fit the concept. The new sequence splits independent invariants and removes those repetitive scaffolds.
Corrections and qualification decisions
| Source evidence | Problem | Treatment |
|---|---|---|
| C21 isolation diagrams versus its own engine-specific matrix | Repeatable Read is described both as preventing lost updates and as engine-dependent. Its simple xmin/xmax picture omits active/aborted transaction visibility. | Lesson 01 uses explicit schedules and PostgreSQL-specific guarantees; MVCC is a snapshot mechanism, not a numeric transaction-ID comparison. PostgreSQL isolation. |
| C04 āNever Update, Always Invalidateā versus L11 Parts 2ā4 | Bare deletion does not defeat an in-flight stale refill. | Lesson 10 traces resurrection and compares versions, leases, and source freshness. |
| C20 revocation Bloom-filter diagram | āDefinitely not revokedā ignores delayed dissemination to the filter. | Lesson 31 distinguishes membership correctness from freshness; strict revocation cannot skip an authoritative check using a stale negative. |
| C03 Bloom sizing derivation | Approximation is later called an exact sizing relationship; volatile write is listed beside atomic OR. | Lesson 05 labels the probability model approximate and requires atomic bit updates or synchronization for concurrent inserts. |
| L01/L02 recovery summaries | A failed checksum is treated as evidence that the record was unacknowledged. That conclusion needs the specific torn-tail failure model. | Lesson 03 separates interrupted append from later corruption of acknowledged data. Never silently truncate middle corruption. |
| C24 active-active text | It says cross-region writes āmustā be asynchronous, although synchronous systems trade latency/availability for stronger guarantees. | Lesson 25 makes replication policy an explicit decision and distinguishes serving traffic from write authority. |
| C13 trie complexity | O(L) prefix navigation is easy to misread as O(L) completion enumeration. | Lesson 32 includes output/subtree cost and top-K maintenance. |
| C17 filtered HNSW illustration | Restricting graph traversal is presented as if it necessarily finds K qualifying results. | Lesson 34 separates filter-aware retrieval from naive graph disconnection and requires filtered exact recall baselines. pgvector filtering. |
| C18 proxy and worker descriptions | Long polling does not necessarily occupy a dedicated thread; āflawlessā proxy compatibility is too strong. | Lesson 30 discusses asynchronous connection resources and actual proxy timeouts/buffering. |
| C19 HTTP/3 comparisons | Eliminating TCP cross-stream ordering is not independence from congestion, flow control, or QPACK dependencies. | Lesson 29 states the narrower transport guarantee. |
| C28/C29 token replay recipes | Claiming a token before validation can strand a legitimate retry after an ambiguous response. | Lesson 36 separates pending validation, verified result, and business idempotency; validates hostname/action. Turnstile validation, reCAPTCHA verification. |
| C30 privacy/decentralization and performance tables | Self-hosting does not imply zero personal data, zero operational dependencies, or uniform device cost. | Lesson 37 states challenge binding, one-time consumption, hardware asymmetry, and measured effort. |
| Several sources' service sizing tables | Thresholds, prices, memory overheads, defaults and maximums are presented alongside fundamental guarantees. | Retain exact tables as source references; new lessons derive workload-specific calculations and avoid undocumented universal thresholds. |
Gaps filled by the new learning path
Atomicity and isolation now precede shared counters and distributed ownership. Failure classes precede durability choices. Idempotency precedes queue effects and outbox consumers. Replication positions and consensus precede fencing; fencing precedes live moves and regional takeover. Cardinality and mergeability precede storage-tier calculations. Challenge verification follows identity and abuse economics, rather than implying a CAPTCHA is a complete account-abuse defense.
The prototypes provide executable local models and explicit schedules. The later lessons revisit those guarantees under new failures instead of repeating definitions. Each final challenge has an answer or criteria so the learner can check the reasoning.
Reference-retained and review-needed material
The inventory is exhaustive at the file/heading/fenced-asset level. This is not a claim that every statement in roughly half a million source words has been independently fact-checked. Large original examples and operational runbooks remain reference-retained, with per-file dispositions in SOURCE_MAPPING. Do not label all 530 assets āportedā or āvalidated.ā
Before adopting source recipes in production, recheck current cloud limits/prices, managed-service replication modes and regional constraints, engine defaults, connector transaction timeouts, CAPTCHA/PAT implementation details, privacy/legal claims, and platform-specific notification replacement behavior. The custom checkpoint-tag cleanup protocol in L04/L07 requires its full sink/restore assumptions; lesson 21 explains those assumptions without advertising that recipe as a general Flink guarantee. Arbitrarily adding a fixed offset after restoring a fencing counter is not a proof of uniqueness; lesson 16 requires an authority that cannot reuse accepted generations.
Primary-document checks in this work focus on disputed isolation behavior, WAL synchronization, Redis script atomicity, streaming time, filtered vector retrieval, and challenge verification. Unverified source vendor examples are not silently corrected or promoted to guarantees. Curriculum routes and link mapping are now implemented and covered by route tests and production prerendering. Live browser interaction remains unverified because the user chose to start the service themselves. The QA report separates these results from content parser checks.