Concept Connection Atlas

Overview

Most technical curricula teach systems as silos: one chapter for virtual memory, one for database indexes, one for TCP. The exam then asks about each in isolation. Production systems and senior interviews do neither — they ask what a page cache, a DB buffer pool, and a CDN edge have in mechanism in common, and where that commonality stops. This atlas exists to answer that kind of question.

The unit of analysis here is the cross-domain connection, and every connection is held to the same five-part standard:

1. Concepts stated independently. Each side of the connection is explained on its own, with just enough mechanism for the link to make sense. If you cannot state both concepts crisply, the connection is decoration, not understanding.
2. The shared principle, named precisely. Not “these are similar” but something testable, e.g., “both are demand-filled caches with locality-driven eviction over a cost gradient” or “both compute a linear extension of a partial order induced by dependencies.” A well-named principle is a transferable tool: next time you meet an unfamiliar system, you can ask “which known principle does this instantiate?”
3. Where the analogy HOLDS and where it BREAKS. Specific and technically honest. An analogy that never breaks is a definition, not an analogy. The breaking points are usually where the interview follow-up question lives (“but what about fan-out?”), and where real design mistakes happen (applying the cache-miss mental model to a page fault that costs 10,000× more).
4. A concrete worked example, with numbers where possible. Mechanisms earn belief through arithmetic: a B+tree that fits a billion keys in 3 levels, an M/M/1 queue whose latency doubles per 10% of utilization near saturation.
5. When the connection is useful. Problem-solving heuristics, interview answers, and real engineering decisions it unlocks — plus the decision it should not be stretched to.

Why this matters for engineering judgment. Mechanism transfer is how senior engineers reason about systems they have never operated. If you know that Git, Nix, Docker layers, IPFS, and content-hashed CDN assets all instantiate “hash the content, not the location,” then a new system described as “content-addressed” immediately implies immutability, cheap integrity checks, dedup, and cache-friendliness — and its costs (GC of unreferenced data, no in-place mutation) are implied too. Without the abstraction, each system looks like isolated trivia.

Why this matters for interviews. Interviewers escalate along the axis of abstraction, not trivia: “What is a B+tree?” (junior) → “Why a B+tree and not a skip list on disk?” (mid) → “What property of the storage medium makes fan-out the dominant term?” (senior). The third question is answered by the principle this atlas names in db-indexes-data-structures.md: data structures are shaped by the physics of the storage medium. The atlas pages are written so each can supply the top of that escalation chain.

Map of the Atlas

Forty-two connection pages, grouped by the kind of shared principle rather than by textbook silo:

                         CONCEPT CONNECTION ATLAS
                         =======================
  ORDERING              dependency-resolution ........ topo sort ~ make ~ npm ~ schedulers
  HIERARCHY / CACHING   virtual-memory-caching ....... demand paging ~ page cache ~ buffer pool ~ CDN
  STORAGE PHYSICS       db-indexes-data-structures ... B+tree ~ LSM ~ skiplist ~ columnar
  QUEUES / DELAY        scheduling-queueing .......... CPU schedulers ~ Kendall notation ~ CoDel
                        backpressure ................. bounded queues ~ TCP windows ~ Kafka pull ~ load shedding
  FAILURE / PROTOCOL    tcp-distributed-failure ...... RTO ~ retries ~ idempotency ~ failure detectors
  CONTENT ADDRESSING    git-cas ...................... Git ~ Nix ~ Docker ~ IPFS ~ restic
  ORDERING CONTRACTS    transactions-concurrency ..... 2PL ~ RW locks ~ MVCC ~ isolation ~ memory models
  LIFETIMES             gc-memory-management ......... reachability ~ refcounts ~ generations ~ leases
  EVENT LOGS            event-sourcing-wal ........... git log ~ WAL ~ event sourcing ~ CDC ~ audit trails
  REPLICATED COPIES     cache-coherence-consistency .. MESI ~ invalidation ~ CDN purge ~ replicated consistency
  OPTIMIZER DAGS        query-planner-dataflow ....... compiler passes ~ query planner ~ Flink DAGs ~ build graphs
  REDUNDANCY            checksums-erasure-coding ..... checksums ~ RAID parity ~ Reed-Solomon ~ hashes ~ ECC
  COORDINATION          consensus-leases ............. Raft ~ distributed locks ~ leases ~ fencing tokens
  EVENT DISPATCH        interrupts-async ............. IRQs ~ signals ~ epoll ~ event loops ~ futures
  INVALIDATION          incremental-computation ...... make ~ spreadsheets ~ incr. compilers ~ matviews ~ React
  ADDRESSING / ROUTING  dns-cdn-routing .............. DNS hierarchy ~ anycast ~ GeoDNS ~ CDN edge ~ purge
  ISOLATION / RESOURCES containers-cgroups-namespaces   namespaces ~ cgroups ~ overlayfs layers ~ OCI runtime
  IDENTITY / STATE      auth-identity-session ........ OAuth2 ~ JWT ~ sessions ~ cookies ~ revocation ~ SSO
  PLACEMENT             load-balancing-partitioning ... L4/L7 ~ affinity ~ consistent hashing ~ discovery
  EXECUTION / SILICON   jit-interpretation-hardware .. interpreter ~ tiered JIT ~ inline caches ~ deopt
  RETRIEVAL             search-inverted-index ........ analyzer ~ postings ~ BM25 ~ segments ~ NRT refresh
  TELEMETRY             observability-pipeline ....... metrics/logs/traces ~ agents ~ sampling ~ cardinality
  RELEASE ENGINEERING   feature-flags-deploy-coupling  flags ~ deploy ~ rollout ~ kill switches ~ cleanup debt
  SHIPPING / SCHEMA     migrations-deploy-coupling ... expand-contract ~ dual-write ~ backfill ~ lock budgets
  ML SERVING            ml-inference-pipeline ........ artifacts ~ feature stores ~ batching ~ drift
  CONFIG DISTRIBUTION   config-management-pipeline ... layering ~ hot reload ~ secrets ~ blast radius
  MONEY AS A LOG        payments-ledger-double-entry . double-entry ~ idempotency ~ reconciliation ~ sagas
  BUILD HONESTY         build-caches-reproducibility . lockfiles ~ content-addressed caches ~ hermetic builds
  CALLBACK DELIVERY     webhook-delivery ............. retries ~ signing ~ dedup ~ DLQ ~ pull fallback
  FEEDBACK ADMISSION    email-delivery-pipeline ...... SPF/DKIM/DMARC ~ reputation ~ warm-up ~ stream isolation
  RECOVERY LOOPS        queue-dead-letter-replay ..... DLQ ~ replay ~ idempotency keys ~ poison quarantine
  ADMISSION STATE       rate-limiting-distributed .... per-instance ~ Redis/Lua ~ edge buckets ~ sync lag
  SEMANTIC RETRIEVAL    search-vector-embedding ...... chunking ~ embeddings ~ ANN ~ reranker ~ eval loop
  CUSTODY CHAINS        deployment-artifact-promotion  digests ~ registries ~ gates ~ provenance ~ rollback
  WIRE CONTRACTS        serialization-schema-evolution  writer/reader schemas ~ registry compat gate ~ CI canary
  WRITE-TIME MEDIA      media-optimization-delivery ... master ~ transcode ladder ~ segments ~ ABR client
  TIME DISTRIBUTION     time-synchronization-infrastructure  strata ~ ppm drift ~ bounded uncertainty
  SECRET CUSTODY        secrets-management-pipeline .... generate ~ vault ~ inject ~ rotate ~ audit
  DATA DAGS             batch-orchestration-lineage .... scheduler ~ partitions ~ backfill ~ lineage
  QUERY FEDERATION      graphql-federation ............. subgraphs ~ supergraph ~ entity joins ~ plans
  ORIGIN ISOLATION      browser-security-model ........ SOP ~ CORS gates ~ cookie scope ~ CSP ~ metadata

Reading order is flexible; the two most load-bearing pages are virtual-memory-caching.md (the caching lens appears in half the other pages) and scheduling-queueing.md (Little’s Law is the quantitative glue reused in backpressure.md).

File Inventory

Coverage Ledger

Status as of tasks 3-c (Round 15), 3-c2 (Round 16), r17-c2 (Round 17), r18-c (Round 18), r19-c (Round 19), and r20-c (Round 20); sibling research-projects/ directories are owned by parallel tasks per the coordinator’s plan — links to them resolve once those tasks land.

Deliberately out of scope for the atlas: generic pattern catalogs (owned by failure-modes/), mechanism-deep single-topic trade-offs (owned by the Why-Not Handbook), and incident timelines (owned by the Failure Casebook). Where those cover a topic, these pages link instead of duplicating.

Interview Questions

1. A candidate explains that “a database buffer pool is basically a cache.” What follow-up questions would you ask to distinguish rote analogy from mechanism understanding, and what answers would satisfy you?
2. Name two systems that share a partial-order dependency structure and one behavioral difference that emerges when a dependency graph contains a cycle.
3. Why is “the disk is just slow RAM” a dangerous simplification when tuning a system that mmaps a large file? Give one workload where mmap loses to explicit read() and say why in terms of fault cost.
4. Your p99 latency doubles as CPU utilization crosses 70%, though average latency barely moves. Construct an explanation using queueing theory alone, naming the law and the variance term.
5. Design-interview framing: “Build me a container registry.” Which named principle from this atlas would structure your answer, and what are the two costs of that principle you would volunteer?

Key Takeaways

• A connection is only worth writing down if it names a precise shared mechanism and states exactly where the mapping fails.
• The same small set of principles — partial order, demand-filled caching, cost-of-the-medium, queue discipline as policy, statistical failure detection, content addressing, ordering contracts, liveness approximation, upstream demand propagation, state as a fold over an immutable log, write-propagation across replicas, cost-based plan selection over DAGs, redundancy converting detection into recovery, grant/lease/fencing stacks, push-based event dispatch, and invalidate-only-what-changed — explains a disproportionate fraction of systems behavior across OS, DBMS, networking, and distributed systems.
• Analogies transfer predictions, not constants: a cache miss at L1 costs ~1 ns, a page fault ~ms; the theory of eviction transfers, the numbers do not.
• Use the Coverage Ledger above to see what is covered, where depth was deliberately deferred to canonical pages, and which sibling research projects own the adjacent angles.

Cross-References

• ../../dsa/README.md — Data Structures and Algorithms Track — where the primitive structures (hash tables, trees, graphs) are taught before the atlas reinterprets them.
• ../../os/overview.md — Operating Systems Overview — canonical treatment of memory, scheduling, and paging that the atlas connects outward.
• ../../dbms/overview.md — Database Management Systems Overview — canonical indexing and transaction content.
• ../../networks/overview.md — Computer Networks — canonical TCP/IP content behind the failure-detection connections.
• ../../distributed/overview.md — Distributed Systems Overview — failure detectors, consistency models, and leases referenced across these pages.
• ../../queueing-theory/fundamentals.md — Queueing Theory Fundamentals — the formal backbone for the scheduling and backpressure pages.
• ../../git/internals.md — Git Internals — object model details behind the content-addressing connection.
• ../../compilers/README.md — Compilers Track — optimization passes and SSA, the compiler side of the planner connection.
• ../../data-engineering/README.md — Data Engineering — Flink/Beam/Debezium pages behind the event-log and dataflow connections.
• ../../arch/overview.md — Computer Architecture — cache hierarchy and memory-hierarchy numbers used throughout.
• ../followup-tree/rate-limiter-design.md — Rate Limiter Design — escalation chains for the rate-limiting half of the backpressure connection.
• ../why-not-handbook/caching-distributed.md — Caching vs Distributed Coordination — the decision-level companion to the caching analogy.
• ../failure-casebook/github-october-2018.md — GitHub October 2018 — the named incident illustrating retry-storm dynamics cited in two atlas pages.