Don't Panic — Distributed Computing Fundamentals

Distributed computing is what happens when one job or service moves from one computer to several independent ones. The machines exchange messages, which sounds civilised until a message takes a scenic route, a machine stops, or both clocks confidently disagree about Tuesday.

The arrangement exists for sensible reasons. One machine may not hold the data, finish the work quickly enough, sit near the people who need it, or survive the failure you care about. Split the input into partitions, give workers separate pieces, and combine the results. This is the MapReduce shape: map work produces intermediate key-value pairs, reduce work combines values by key, and the runtime handles scheduling, movement, and failed tasks. The impressive part is not the arrows. It is deciding which arrows are allowed to misbehave.

The first surviving idea is partial failure. A local function usually returns, errors, or keeps running. A remote operation adds the wonderfully unhelpful fourth state: no reply. After a timeout, the server may have missed the request, completed it, or still be working. The timeout reports waiting time, not history. That is why an idempotent operation, one whose repeat has the same intended effect, needs a stable operation ID. It lets a retry ask about the same logical work instead of quietly ordering a second helping.

The second idea is that time is not a shared household appliance. Happened-before records causal order: work earlier in one process, a sent message before its received message, and chains of those relations. Events with no such path are concurrent. A logical clock can respect this order, but it is not a tiny judge wearing a wall-clock costume.

Then there is shared state, which is where the furniture begins to move. Replication keeps copies of logical state, improving some failure and read options while creating rules about accepted updates and reads. A consistency model names the observations clients may see. When one ordered history matters, consensus and a replicated log let a communicating majority commit commands for deterministic state machines. The minority does not get a competing history merely because it is feeling independent.

Start with the Intro for the full architecture and failure model. Use Slides when you want the relationships in one pass. Keep the Cheatsheet beside design and incident work for timeout outcomes, partitioning, consistency, safety, and liveness. The Practice Reference and exercise turn the lost-reply problem into a testable operation registry. The Timeline supplies the older landmarks; Field Notes covers the operational traps those landmarks do not politely announce.

Don't Panic — Distributed Computing Fundamentals

Relevant careers