MapReduce: Simplified Data Processing on Large Clusters
Jeffrey Dean, Sanjay Ghemawat2004OSDI 2004 / CACM 2008
Read it on doi.org(opens in a new tab)Why this one
Read this less for MapReduce itself - which you will probably never write - and more for what it says about failure. On a thousand machines something is always broken, so the programming model is chosen precisely because it makes recovery boring: a map task is pure, so a dead worker's task is simply run again somewhere else, and nobody has to reason about partial state. That is the transferable idea, and it is the reason the paper still earns a place in a 2026 syllabus. The section on stragglers and backup tasks is the other half of the value: it is the first place most engineers meet the fact that the slowest node, not the failed node, is what determines your job's wall-clock time.
What to take away
- Deterministic, side-effect-free tasks make retries free. Design for that and fault tolerance stops being a feature.
- Stragglers dominate tail latency in any fan-out system, batch or online.
- The shuffle is where the network cost lives - the same lesson reappears in every distributed query engine since.
Reads with
- The Google File System
mapreduce assumes this chunked replicated storage layer underneath it
- Resilient Distributed Datasets: A Fault-Tolerant Abstraction for In-Memory Cluster Computing
keeps mapreduce's recomputation idea but makes iterative jobs fast in memory
- The Tail at Scale
turns mapreduce's straggler problem into a general latency design principle