Learn Next — Compute Recommendation Graph
If you’ve worked through one Compute note, what should you read next to gain the most leverage? This guide is a learning-path overlay on top of the per-topic notes and the two _compare_* synthesis notes (consistency models, service architectures). The recommendations follow the actual dependency structure of the library: networking, OS, and concurrency are the substrate; databases and distributed systems sit on top; ML/AI is a vertical that uses everything below it.
How to use this guide
For each per-topic note, you get one to three “next” recommendations tagged:
- (foundation) — a layer below this one that explains why the patterns exist.
- (application) — same idea applied to a domain (web, ML, storage).
- (synthesis) — a
_compare_*note that ties this topic into the wider decision space. - (adjacent) — a sibling concept that shows up in the same job interview.
Read in groups; the Reading paths section composes them into named multi-step tracks (Distributed-systems engineer, Database engineer, ML platform engineer, Cloud-native SRE, Security engineer).
Foundational track — the substrate
From networking-foundations
- → http2-http3-quic (application): The modern transport layer that every API service in 2026 actually runs on; HTTP/2 multiplexing and HTTP/3 over QUIC are where the latency budget gets won or lost.
- → cryptography-fundamentals (foundation): TLS, certificates, key exchange — the security layer that wraps every network call.
- → distributed-systems-fundamentals (application): Networks are unreliable; that observation is the entire starting point of distributed systems theory.
From os-scheduling-memory
- → concurrency-primitives (foundation): Threads, locks, atomics, lock-free, async — the layer above scheduling that you actually program against.
- → cpu-cache-performance (application): Memory hierarchy is what makes scheduling decisions matter — false sharing, NUMA, prefetch.
- → garbage-collection (application): GC is the OS-style memory management you build inside a language runtime.
From concurrency-primitives
- → lock-free-data-structures-and-rdma (foundation): When locks become the bottleneck, lock-free + RDMA is the next layer down.
- → distributed-systems-fundamentals (application): Concurrency primitives generalize to distributed primitives — locks → leases, atomics → consensus.
- → _compare_consistency_models (synthesis): Once you understand single-machine ordering, the multi-machine ordering hierarchy follows.
From cpu-cache-performance
- → lock-free-data-structures-and-rdma (application): Cache lines + memory ordering are the foundation of lock-free queues, hazard pointers, RCU.
- → ebpf-and-kernel-observability (method): eBPF lets you measure cache misses, scheduler latency, and syscall overhead in production.
- → cuda-triton-gpu-programming (application): GPUs have an even deeper memory hierarchy; the same mental model scales.
From compiler-design
- → compilers-and-program-analysis (foundation): Beyond syntax + IR — type inference, dataflow analysis, abstract interpretation, SMT-backed verification.
- → garbage-collection (application): GCs are compiler-runtime co-design; the compiler emits read/write barriers the GC needs.
- → formal-verification-and-fuzzing (adjacent): Modern compilers and verifiers share infrastructure (LLVM, SMT solvers, abstract interpretation).
From garbage-collection
- → cpu-cache-performance (foundation): GC throughput is dominated by cache behavior — generational hypothesis, card-marking, write barriers all live in the cache.
- → compiler-design (foundation): The compiler emits the safepoints + barriers a moving GC needs.
Distributed-systems track
From distributed-systems-fundamentals
- → consensus-protocols (foundation): Raft, Paxos, Zab — the building blocks every CP system uses underneath.
- → _compare_consistency_models (synthesis): The “what does System X actually promise” hierarchy across linearizable → causal → eventual.
- → crdts-and-distributed-data-types (application): When you can’t afford a CP system, CRDTs give you strong-eventual convergence.
From consensus-protocols
- → databases-internals-deep (application): Raft / Paxos under CockroachDB, etcd, TiDB, Spanner — see consensus deployed in actual storage engines.
- → _compare_consistency_models (synthesis): The consistency-model space consensus enables.
- → networking-foundations (foundation): Why heartbeats, leases, and term numbers exist — because network partitions exist.
From crdts-and-distributed-data-types
- → _compare_consistency_models (synthesis): The strong-eventual + causal+ corner of the hierarchy.
- → databases-internals-deep (application): How AntidoteDB, Redis CRDTs, Riak, and Automerge implement CRDTs.
- → distributed-systems-fundamentals (foundation): Vector clocks and causal delivery — the math underneath every CRDT.
From microservices-patterns
- → _compare_service-architectures (synthesis): The full monolith → modular → microservices → serverless decision space, with real exemplars (Netflix, Shopify, Uber DOMA, Amazon Prime Video monolith reversal).
- → containers-service-mesh (application): How microservices actually get deployed — Envoy, Istio, Linkerd, mTLS, retries, circuit breakers.
- → observability-stack (foundation): You cannot operate microservices without traces, metrics, and structured logs.
Database track
From database-internals
- → databases-internals-deep (foundation): B-trees vs LSM trees, MVCC, WAL, page cache, query planning — the actual engine internals.
- → sql-nosql-design (adjacent): The schema-design and access-pattern decisions that sit on top of the engine.
- → _compare_consistency_models (synthesis): What each database actually promises about isolation, replication, and partition behavior.
From sql-nosql-design
- → database-internals (foundation): Schema design without engine knowledge is cargo-culting; learn what the engine actually does with your queries.
- → database-engine-taxonomy (foundation): The full catalog of Postgres / MySQL / Mongo / Cassandra / ClickHouse / DuckDB to pick from.
- → _compare_consistency_models (synthesis): The “is my read going to see my own write?” question, answered system by system.
From databases-internals-deep
- → consensus-protocols (foundation): Replication = consensus underneath; CockroachDB, TiDB, Spanner all use Raft / Paxos variants.
- → crdts-and-distributed-data-types (adjacent): The alternative replication strategy when you don’t want consensus.
- → rag-embeddings-vector-search (application): The newest indexing problem databases face — high-dimensional vector indexes (HNSW, IVF, ScaNN).
From rag-embeddings-vector-search
- → transformer-architecture (foundation): Embeddings come out of the same transformer stack; understanding it lets you reason about embedding quality.
- → vector-database-taxonomy (application): The catalog of Pinecone / Weaviate / Qdrant / Milvus / pgvector / LanceDB to pick from.
- → databases-internals-deep (foundation): Vector indexes are a database index family; the same B-tree-vs-LSM-vs-bitmap thinking applies.
ML/AI track
From transformer-architecture
- → fine-tuning-rlhf (application): Post-training — SFT, DPO, RLHF, GRPO — what turns a base model into a useful assistant.
- → inference-optimization (application): KV cache, quantization, speculative decoding, FlashAttention — how transformers actually get served at scale.
- → linear-algebra-essentials (foundation, cross-library): Attention is matrix multiplication; you need the linear-algebra view to reason about it.
From fine-tuning-rlhf
- → inference-optimization (application): The trained model is useless if you can’t serve it cheaply.
- → prompt-engineering-agent-systems (adjacent): Often you don’t need to fine-tune; prompt + tool-use + retrieval beats fine-tuning for most tasks.
- → reinforcement-learning-theory (foundation, cross-library): RLHF is RL; PPO / GRPO / DPO all live in the policy-gradient / preference-learning family.
From inference-optimization
- → cuda-triton-gpu-programming (foundation): FlashAttention, FlashInfer, PagedAttention all live in CUDA; without GPU programming, you can’t move the needle.
- → model-serving-infrastructure (application): vLLM, TGI, TensorRT-LLM, SGLang — the actual serving stacks.
- → fpga-and-hardware-acceleration (adjacent): When GPUs aren’t right (low-latency trading, edge), FPGAs and custom ASICs are the next stop.
From cuda-triton-gpu-programming
- → inference-optimization (application): What you’ll spend most of your GPU code budget on in 2026.
- → cpu-cache-performance (foundation): The same memory-hierarchy thinking, just with shared memory + warps + tensor cores.
- → numerical-linear-algebra (foundation, cross-library): GEMM, GEMV, batched-matmul performance is where 95% of CUDA tuning time goes.
From prompt-engineering-agent-systems
- → rag-embeddings-vector-search (application): Retrieval is the main mechanism that gives agents grounded context.
- → transformer-architecture (foundation): To debug agent failures you need to understand the model that produces them.
- → observability-stack (application): Agent tracing (LangSmith, Phoenix, Helicone) is observability for LLM calls.
Cloud-native + operations track
From kubernetes-deep
- → containers-service-mesh (application): K8s + Envoy/Istio is the canonical deployment substrate for microservices.
- → observability-stack (foundation): Prometheus, OpenTelemetry, Grafana, Loki — the visibility layer K8s desperately needs.
- → _compare_service-architectures (synthesis): The “do we even need K8s?” decision, with real exemplars from monolith to serverless.
From containers-service-mesh
- → kubernetes-deep (foundation): The orchestrator your mesh actually runs on.
- → networking-foundations (foundation): mTLS, eBPF data planes (Cilium), HTTP/2 + gRPC — service mesh sits on top of these.
- → ebpf-and-kernel-observability (adjacent): Modern meshes (Cilium, Istio Ambient) are sidecar-less because of eBPF.
From observability-stack
- → ebpf-and-kernel-observability (foundation): The deepest layer of observability — kernel-level tracing without instrumentation.
- → observability-tools-catalog (application): Prometheus / Grafana / Datadog / Honeycomb / New Relic — which tool for which problem.
- → distributed-systems-fundamentals (foundation): Tracing only makes sense after you understand happens-before and causal ordering.
From ebpf-and-kernel-observability
- → os-scheduling-memory (foundation): eBPF is observable kernel internals; without OS knowledge it’s just opaque graphs.
- → observability-stack (application): Where eBPF data ends up — Pixie, Parca, Pyroscope, Cilium Hubble.
- → cpu-cache-performance (adjacent): eBPF + perf is the modern way to chase cache misses and false sharing.
Security track
From cryptography-fundamentals
- → auth-authz (application): OAuth, OIDC, SAML, JWT, mTLS — cryptography assembled into authentication systems.
- → differential-privacy-and-privacy-tech (application): The next layer beyond crypto — releasing useful data without leaking identities.
- → networking-foundations (foundation): TLS, certificate pinning, HSTS — cryptography wrapped around every TCP connection.
From auth-authz
- → cryptography-fundamentals (foundation): To trust JWT signatures, PKCE, and token rotation you need to understand the primitives.
- → auth-provider-catalog (application): Auth0 / Clerk / WorkOS / Stytch / Okta — pick a provider rather than rolling your own.
- → microservices-patterns (adjacent): Service-to-service auth (SPIFFE, mTLS, service mesh identity) is where auth meets architecture.
From differential-privacy-and-privacy-tech
- → cryptography-fundamentals (foundation): Crypto + DP together cover most privacy-engineering requirements.
- → information-theory (foundation, cross-library): Mutual information, entropy, and KL divergence are the math of privacy guarantees.
- → rag-embeddings-vector-search (adjacent): Federated learning + DP + secure aggregation is where ML meets privacy.
From formal-verification-and-fuzzing
- → compilers-and-program-analysis (foundation): Abstract interpretation, dataflow, type systems — the static-analysis substrate.
- → cryptography-fundamentals (application): Verified crypto (HACL*, fiat-crypto, EverCrypt) is the leading deployment of formal methods in production.
Specialty + frontier
From fpga-and-hardware-acceleration
- → cuda-triton-gpu-programming (adjacent): The GPU and FPGA paths share thinking about parallelism, memory hierarchy, and data movement.
- → inference-optimization (application): Where FPGAs / ASICs make the most economic sense in 2026 — LLM inference at scale.
- → fpga-design (foundation, cross-library): The hardware-design view of FPGAs.
From _compare_consistency_models
- → _compare_service-architectures (synthesis): The other major architectural decision — once you know your consistency budget, you can pick your service decomposition.
- → databases-internals-deep (application): How specific engines implement each model.
- → crdts-and-distributed-data-types (foundation): The strong-eventual corner you’ll reach for when consensus is too expensive.
From _compare_service-architectures
- → _compare_consistency_models (synthesis): The other major architectural decision — once you know your services, you need their data model.
- → microservices-patterns (application): The specific patterns (saga, outbox, CQRS, event-sourcing) the architectures use.
- → observability-stack (foundation): The operational floor every architecture rests on.
Reading paths
Distributed-Systems Engineer Track
For someone building globally distributed databases or coordination systems:
networking-foundations → concurrency-primitives → distributed-systems-fundamentals → consensus-protocols → _compare_consistency_models → crdts-and-distributed-data-types → databases-internals-deep → probability-fundamentals
Database Engineer Track
For someone working on a query planner, storage engine, or replication layer:
os-scheduling-memory → cpu-cache-performance → database-internals → sql-nosql-design → databases-internals-deep → _compare_consistency_models → consensus-protocols → rag-embeddings-vector-search
ML Platform Engineer Track
For someone building the training + inference platform a research org runs on:
linear-algebra-essentials → transformer-architecture → fine-tuning-rlhf → cuda-triton-gpu-programming → inference-optimization → model-serving-infrastructure → rag-embeddings-vector-search → observability-stack
Cloud-Native SRE Track
For someone on-call for a multi-region Kubernetes platform:
networking-foundations → os-scheduling-memory → containers-service-mesh → kubernetes-deep → observability-stack → ebpf-and-kernel-observability → microservices-patterns → _compare_service-architectures
Security Engineer Track
For someone designing auth + privacy for a regulated product:
networking-foundations → cryptography-fundamentals → auth-authz → differential-privacy-and-privacy-tech → formal-verification-and-fuzzing → compilers-and-program-analysis → number-theory
Adjacent libraries — when you’ve finished this library
- Math — every Compute topic has a Math foundation: probability for distributed systems, linear algebra for ML, information theory for privacy and compression, number theory for crypto. Start with probability-fundamentals, linear-algebra-essentials, information-theory.
- Languages — the syntax + library + runtime catalog. Pair garbage-collection with Java or Go; pair concurrency-primitives with Rust or Elixir; pair cuda-triton-gpu-programming with Python.
- Engineering — the hardware that runs the compute. microcontrollers, realtime-embedded, fpga-design are the natural continuations of the lower-level Compute notes.
- Robotics — the application domain that uses Compute (perception, planning, control) on top of Engineering (actuators, sensors, mechanisms).
Notes
This is opinionated synthesis. A backend SaaS engineer and an ML research engineer will use the same Compute library very differently — that is intentional. The recommendations come from the actual cross-reference structure of the per-topic notes, the two _compare_* syntheses, and the canonical paths through systems-engineering interview prep.