Learning path
Distributed Systems Engineering learning path: everything to study, topic by topic
Comprehensive distributed systems assessment covering consistency models, replication strategies, scalability patterns, fault tolerance, storage engines, and distributed transactions. Based on Designing Data-Intensive Applications (Kleppmann).
Short answer
To learn Distributed Systems Engineering, work through 6 modules and 24 topics in the order they build on each other. It starts with Data Consistency Models, then moves on to Replication & Consensus and Scalability & Performance. Use the map as a checklist, or measure your level and study only what is missing.
What you will study
Topics are grouped by module. Open one to see its objectives and key concepts.
1 · Data Consistency Models4 topics
CAP Theorem
Understanding the CAP theorem — Consistency, Availability, and Partition Tolerance — and the real-world tradeoffs distributed system designers must make when network partitions occur
Objectives
- Explain the CAP theorem and why all three properties cannot be simultaneously guaranteed
- Classify real systems (Cassandra, HBase, Zookeeper) along the CAP spectrum
Key concepts
- CAP theorem
- consistency
- availability
- partition tolerance
- CA vs CP vs AP systems
- network partitions
- PACELC model
Consistency Models
The spectrum of consistency guarantees — from strict serializability to read-your-writes, monotonic reads, and session consistency — and when each is appropriate
Objectives
- Describe the consistency model spectrum from strongest to weakest
- Select the appropriate consistency model for a given application requirement
Key concepts
- strong consistency
- weak consistency
- read-your-writes
- monotonic reads
- session consistency
- causal consistency
- serializability
Eventual Consistency
How eventually consistent systems converge, conflict resolution strategies including last-write-wins and CRDTs, and the application design patterns needed to handle staleness
Objectives
- Explain how eventually consistent systems converge toward a consistent state
- Design conflict resolution strategies for multi-writer systems
Key concepts
- eventual consistency
- conflict resolution
- last-write-wins
- CRDTs
- vector clocks
- read repair
- anti-entropy
Linearizability & Sequential Consistency
Linearizability as the strongest single-object consistency guarantee, its cost in latency and availability, and the distinction from serializability for multi-object operations
Objectives
- Formally define linearizability and distinguish it from serializability
- Evaluate the latency and availability cost of enforcing linearizability in production
Key concepts
- linearizability
- sequential consistency
- total order
- atomic operations
- compare-and-swap
- distributed locking
- fencing tokens
2 · Replication & Consensus4 topics
Replication Strategies
Single-leader, multi-leader, and leaderless replication architectures — their write paths, read paths, durability guarantees, and operational trade-offs
Objectives
- Compare single-leader, multi-leader, and leaderless replication architectures
- Choose a replication strategy given durability, latency, and consistency requirements
Key concepts
- single-leader replication
- multi-leader replication
- leaderless replication
- synchronous replication
- asynchronous replication
- quorum reads/writes
- replication factor
Replication Lag & Anomalies
The problems caused by replication lag — read-after-write violations, monotonic read failures, causality violations — and the techniques to detect and mitigate them
Objectives
- Identify and diagnose replication lag anomalies in production systems
- Implement application-layer mitigations for common replication lag issues
Key concepts
- replication lag
- read-after-write consistency
- monotonic reads
- causality violations
- replication slots
- logical clocks
- lag monitoring
Leader Election
How distributed systems elect and maintain a leader — including split-brain prevention, epoch numbers, fencing, and the role of external coordination services
Objectives
- Explain how epoch-based leader election prevents split-brain scenarios
- Design a leader election mechanism that is safe under network partition
Key concepts
- leader election
- split-brain
- epoch numbers
- fencing tokens
- ZooKeeper
- etcd
- lease-based leadership
Multi-Leader & Leaderless Replication
Multi-datacenter replication topologies, circular and star topologies, write conflicts, and leaderless systems (Dynamo-style) with tunable quorums
Objectives
- Design a multi-datacenter replication topology with defined conflict resolution
- Evaluate the consistency vs availability tradeoff in Dynamo-style leaderless systems
Key concepts
- multi-datacenter replication
- write conflict detection
- circular topology
- star topology
- Dynamo-style replication
- sloppy quorum
- hinted handoff
3 · Scalability & Performance4 topics
Sharding & Partitioning
Data partitioning strategies — range partitioning, hash partitioning, and directory-based — including hotspot avoidance, rebalancing, and cross-shard query challenges
Objectives
- Select a partitioning strategy that avoids hotspots given a workload's access patterns
- Design a rebalancing strategy that minimizes data movement during cluster expansion
Key concepts
- horizontal partitioning
- range partitioning
- hash partitioning
- hotspots
- rebalancing
- cross-shard queries
- secondary indexes on partitioned data
Consistent Hashing
How consistent hashing distributes load and data across nodes, virtual nodes for improved balance, and its application in distributed caches and databases
Objectives
- Explain why consistent hashing minimizes data movement when nodes are added or removed
- Implement virtual nodes to improve load balance across heterogeneous hardware
Key concepts
- consistent hashing
- hash ring
- virtual nodes
- node addition/removal
- minimal data movement
- load distribution
- rendezvous hashing
Load Balancing
Load balancing algorithms — round-robin, least-connections, power-of-two-choices — health checking, session affinity, and L4 vs L7 load balancing trade-offs
Objectives
- Compare load balancing algorithms and explain when each is appropriate
- Design a load balancing strategy for stateful services requiring session affinity
Key concepts
- round-robin
- least-connections
- power-of-two-choices
- health checks
- session affinity
- L4 vs L7 load balancing
- weighted load balancing
Distributed Caching
Cache invalidation strategies, cache stampede prevention, write-through vs write-behind vs cache-aside patterns, and distributed cache consistency challenges
Objectives
- Select a cache invalidation strategy appropriate for a given consistency requirement
- Design a cache warming strategy that prevents stampede on cold start
Key concepts
- cache invalidation
- cache stampede
- write-through cache
- write-behind cache
- cache-aside pattern
- TTL strategy
- distributed cache consistency
4 · Reliability & Fault Tolerance4 topics
Fault Tolerance Design
Designing systems that tolerate node failures, network partitions, and partial failures — including redundancy, graceful degradation, bulkheads, and failure mode analysis
Objectives
- Apply bulkhead and graceful degradation patterns to isolate failure domains
- Conduct a failure mode analysis for a multi-service distributed system
Key concepts
- fault tolerance
- redundancy
- graceful degradation
- bulkhead pattern
- failure mode analysis
- FMEA
- partial failure
Byzantine Fault Tolerance
Byzantine failures where nodes send conflicting or malicious information, the Byzantine Generals Problem, BFT consensus algorithms, and their applicability in production systems
Objectives
- Explain the Byzantine Generals Problem and why crash fault tolerance is insufficient for it
- Evaluate when BFT consensus is warranted versus standard CFT consensus
Key concepts
- Byzantine fault tolerance
- Byzantine Generals Problem
- PBFT
- BFT consensus
- malicious nodes
- trust models
- blockchain consensus
Circuit Breakers & Timeouts
Circuit breaker state machines (closed/open/half-open), timeout design, retry strategies with exponential backoff, and jitter to prevent thundering herd on recovery
Objectives
- Implement a circuit breaker with appropriate thresholds and recovery behavior
- Design a retry strategy with jitter that prevents thundering herd on service recovery
Key concepts
- circuit breaker pattern
- closed/open/half-open states
- timeout design
- exponential backoff
- jitter
- retry budgets
- thundering herd
Backpressure & Flow Control
Backpressure mechanisms to prevent producer/consumer overload, rate limiting strategies, load shedding, and reactive streams for flow-controlled pipelines
Objectives
- Design a backpressure mechanism for an async pipeline with variable throughput
- Select a rate limiting algorithm appropriate for burst traffic and sustained load
Key concepts
- backpressure
- flow control
- rate limiting
- load shedding
- token bucket
- leaky bucket
- reactive streams
5 · Storage Systems4 topics
Storage Engine Internals
B-tree vs LSM-tree storage engine trade-offs, read amplification, write amplification, space amplification, and why each engine suits different workload profiles
Objectives
- Compare B-tree and LSM-tree engines across the read/write/space amplification triangle
- Select a storage engine architecture given a workload's read/write ratio and latency targets
Key concepts
- B-tree
- LSM-tree
- read amplification
- write amplification
- space amplification
- memtable
- SSTables
Write-Ahead Log (WAL)
How write-ahead logging provides crash recovery guarantees, WAL-based replication, checkpointing, and the interplay between WAL and storage engine durability
Objectives
- Explain how WAL guarantees durability and enables crash recovery
- Describe how PostgreSQL uses WAL for both crash recovery and streaming replication
Key concepts
- write-ahead log
- crash recovery
- WAL-based replication
- checkpointing
- log sequence number
- fsync
- group commit
LSM-Tree Compaction
LSM-tree compaction strategies — size-tiered, leveled, and FIFO — their impact on read/write amplification, space usage, and latency spikes in production
Objectives
- Compare size-tiered and leveled compaction strategies for read-heavy vs write-heavy workloads
- Diagnose and mitigate compaction debt causing latency spikes in production
Key concepts
- LSM-tree compaction
- size-tiered compaction
- leveled compaction
- FIFO compaction
- compaction debt
- bloom filters
- compaction throttling
Columnar Storage & OLAP
Column-oriented storage layouts, compression techniques (run-length encoding, bitmap indexes), vectorized execution, and why columnar formats (Parquet, ORC) accelerate analytical queries
Objectives
- Explain why columnar storage outperforms row storage for aggregation-heavy OLAP queries
- Select between row and columnar storage formats given a workload's query patterns
Key concepts
- columnar storage
- row vs column layout
- run-length encoding
- bitmap indexes
- vectorized execution
- Parquet
- predicate pushdown
6 · Distributed Transactions4 topics
ACID vs BASE
ACID transaction properties (atomicity, consistency, isolation, durability) contrasted with BASE (Basically Available, Soft state, Eventual consistency) and the design implications of each
Objectives
- Define all four ACID properties with concrete examples of what each prevents
- Select between ACID and BASE approaches given an application's consistency requirements
Key concepts
- atomicity
- consistency
- isolation
- durability
- BASE
- isolation levels
- dirty reads
- phantom reads
Two-Phase Commit & Sagas
Two-phase commit protocol for distributed atomicity, its failure modes (coordinator crash, blocking), and saga pattern as a choreography-based alternative for long-running transactions
Objectives
- Explain the blocking failure mode of 2PC and why it is problematic in high-availability systems
- Design a saga with compensating transactions for a multi-service order processing workflow
Key concepts
- two-phase commit
- prepare phase
- commit phase
- coordinator crash
- blocking protocol
- saga pattern
- compensating transactions
Consensus Algorithms (Paxos & Raft)
Paxos and Raft consensus protocols for achieving agreement in the presence of failures, log replication, leader-based coordination, and production systems that implement them
Objectives
- Explain the phases of Raft consensus — leader election, log replication, and safety
- Compare Paxos and Raft in terms of understandability and production implementation complexity
Key concepts
- Paxos
- Raft
- log replication
- leader-based consensus
- quorum
- term numbers
- log compaction with snapshots
Gossip Protocols & Cluster Membership
Gossip-based dissemination for cluster membership, failure detection (SWIM protocol), and epidemic broadcast — how decentralized protocols achieve eventual consistency across large clusters
Objectives
- Explain how gossip protocols propagate information and achieve eventual consistency without a central coordinator
- Describe how the SWIM protocol detects and disseminates node failures in large clusters
Key concepts
- gossip protocol
- epidemic broadcast
- SWIM protocol
- failure detection
- phi accrual failure detector
- cluster membership
- anti-entropy gossip
Levels: Junior, Mid, Senior, and Expert
Explain it in your own words
Graded by AI · no account · 1 questionNo options to guess from: you write, the AI grades against the topic's rubric and tells you what level your answer reads at.
Already studying Distributed Systems Engineering?
The assessment measures topic by topic, and your plan skips what you already know.
Open to read. An account is only needed to be measured.
Frequently asked questions
Where should I start studying Distributed Systems Engineering?
Start with Data Consistency Models: CAP Theorem, Consistency Models, and Eventual Consistency. The map orders topics by what they depend on, so each one prepares the next.
How long does a full Distributed Systems Engineering assessment take?
A full assessment of this path takes about 60 minutes. Study time depends on where you start; a diagnostic shows which topics you can skip.
Do I need an account to use this page?
No. The map, objectives and key concepts are open. You only need an account to be measured, get your gap by topic and receive a plan.