Lecture 1: Introduction

What this lecture covers

This opening lecture asks why anyone builds distributed systems at all, given that a single computer is always simpler, and lays out the reasons: performance through parallelism, fault tolerance, physically separated problems, and security isolation. It then works through the core challenges that make distributed systems hard, namely concurrency, partial failure, and the difficulty of turning more computers into proportionally more performance.

As the first lecture in MIT's Distributed Systems course, it also sets expectations for how the class runs: reading a paper before each lecture, four programming labs building toward a sharded, fault-tolerant key-value store, and two exams. It closes with a detailed walkthrough of MapReduce, the case study for the week, showing how a simple map/reduce programming model can be executed reliably across thousands of machines. After watching, you should be able to explain what makes distributed systems hard, describe the course's lab sequence, and trace how a MapReduce job moves data from input files through map and reduce tasks to output.

Key ideas

• Distributed system: a set of cooperating computers communicating over a network to complete one coherent task.
• Scalability: adding more computers should yield a proportional increase in performance; in practice a single component (often a database) becomes a bottleneck and limits this.
• Partial failure: unlike a single computer, which mostly either works or is down, a system of many computers can have some parts working and others failing at the same time.
• Availability vs. recoverability: an available system keeps serving requests despite some failures; a recoverable system stops on failure but resumes correctly once repaired.
• Consistency: the rules that define what a read returns relative to earlier writes, especially when data is replicated; strong consistency guarantees the latest write is seen, weak consistency does not.
• Non-volatile storage and replication: the two main tools for fault tolerance, used to survive crashes and to keep serving requests when a copy fails.
• MapReduce: a framework where programmers write simple map and reduce functions and the framework handles distributing the work, moving data (the "shuffle"), and tolerating failures.

Walkthrough

Why build distributed systems, and why they're hard (0:01)

The lecture opens by defining a distributed system and arguing you should avoid building one unless a single computer genuinely cannot do the job. The four reasons people build them anyway are performance (parallelism across many CPUs and disks), fault tolerance (redundant computers), problems that are inherently spread across locations, and security isolation between mutually distrusting components. The lecture then explains why these systems are hard to build: concurrency introduces timing-dependent bugs, partial failures create unpredictable states that a single machine never has, and achieving the performance you expect from adding more machines takes careful design.

Course structure and labs (7:13)

The instructor describes the course mechanics: lectures built around case-study papers (one due before each class, with a short question and answer submitted beforehand), a midterm and final exam, and four programming labs. Lab 1 implements a simplified MapReduce, Lab 2 uses the Raft protocol for fault tolerance, Lab 3 builds a replicated key-value server on top of Raft, and Lab 4 shards that key-value store across multiple replicated groups for parallel performance. Students may substitute an original team project for Lab 4.

Scalability and fault tolerance (17:23)

Using a web server plus database example, the lecture shows how adding more web servers can scale a system smoothly until the shared database becomes the bottleneck, illustrating why scalability rarely extends indefinitely without redesign. It then turns to fault tolerance: at large scale, failures that would be rare on one machine become routine (roughly three failures a day across a thousand machines), so systems must be designed assuming something is always broken. The two central defenses are non-volatile storage, for recovering state after a crash, and replication, for continuing to serve requests when one copy fails.

Consistency and the cost of correctness (36:37)

Using a key-value store with put and get operations, the lecture shows how replication can lead a client to read stale data if a write reaches only one replica before a crash. It contrasts strong consistency, where a get is guaranteed to return the most recent put, with weaker consistency models that allow stale reads in exchange for avoiding expensive cross-replica communication. The lecture notes that placing replicas far apart for fault tolerance (different data centers or continents) makes strong consistency more expensive, since confirming a write may require tens of milliseconds of network round trips.

MapReduce as a case study (46:43)

The lecture introduces MapReduce as the framework Google built so that engineers who were not distributed-systems specialists could still run huge computations, such as indexing the web, across thousands of machines. A programmer writes only a map function, which turns an input file into key-value pairs, and a reduce function, which processes all values sharing one key; the framework handles splitting input, scheduling tasks across worker machines, and combining results. The word-count example shows how simple these functions can be: map emits (word, 1) for every word, and reduce sums the values for each word.

How a MapReduce job actually runs (1:02:55)

A master server assigns map and reduce tasks to worker machines. Map output is written to local disk rather than sent over the network immediately, and the system tries to run each map task on the same machine that stores its input in GFS (the Google File System), minimizing network traffic. The "shuffle" step, where each key's values are gathered from every worker onto the machine running its reduce task, is where most network communication happens, and in the 2004 paper this was the main performance bottleneck, since each machine's share of the network was only about 50 megabits per second. The lecture notes that modern data center networks, with multiple root switches, no longer force this constraint, and that Google eventually moved on from MapReduce.

Before you watch

• No prior lecture is required; this is the first lecture of the course.
• Basic familiarity with programming and with the idea of a network connecting computers is assumed.
• It helps to have skimmed the MapReduce paper, since the lecture discusses it in detail without re-explaining every detail from scratch.

Check your understanding

1. Why does the lecture argue you should avoid building a distributed system if a single computer can do the job?
2. What is the difference between an available system and a recoverable system?
3. In the key-value store example, how can a client end up reading a stale value after a replica crash?
4. Why did the "shuffle" step dominate MapReduce's runtime in the 2004 Google paper, and what trick did Google use to reduce network traffic during the map phase?
5. What does it mean for a system to achieve scalable speedup, and why does it typically stop scaling at some point?