liveBook · Manning

Distributed system

As explained in Think Distributed Systems

A computing system whose components execute across multiple networked locations and must coordinate despite having incomplete views of system state.

A distributed system is a collection of collaborating, concurrent components that communicate by sending and receiving messages over a network. Its behavior emerges from both the components and their interactions. Distribution supports correctness, scalability, and reliability because one component cannot handle unbounded load or survive inevitable failures alone. section 1.0 section 1.9

Each component exclusively controls its local state, while the network controls messages in flight. The system can be modeled as a state machine: one component or the network takes one discrete step at a time, either communicating externally or computing internally. section 1.4 section 1.3.1

Reason about a distributed system through several complementary dimensions:

  • Model the network either as a shared communication bus with message buffers or as a bus whose components hold those buffers; both models capture loss, duplication, and reordering. section 1.3.1
  • Change resolution by treating a subsystem as one component or as a collection of communicating components; holons and holarchies help represent these nested organizations. section 1.5.1
  • Separate the global view from the local view: an observer may see the whole system, but each component sees only its own state and limited information. section 1.7.3 section 1.7.4
  • Judge the resulting guarantees through correctness, including safety and liveness, alongside scalability and reliability. section 1.9

Distributed Systems Incorporated

Imagine an office building whose rooms are independent components, pneumatic tubes carry messages between rooms, and a mailbox connects the building to the outside world. A worker may lose, duplicate, or reorder messages; workers may also pause or leave. Simple local rules can therefore produce complex system behavior. section 1.6 section 1.7.1

Figure 1.2 Different models describing the same aspects of a system. (The sets of facts for each model completely overlap.)
A diagram of a diagram

AI-generated content may be incorrect.

Compare equivalent models of the same distributed system to see which facts remain unchanged when message buffers move between the network and components. section 1.3.1

Figure 1.18 Splitbrain
A black and white image of people sitting at desks

AI-generated content may be incorrect.

Use the split-brain illustration to examine how components with local knowledge can violate a global requirement such as having exactly one leader. section 1.7.4

How Think Distributed Systems covers it

How deep it goes
Defines components, local state, messages, network steps, and system models, then stops short of implementing particular protocols.
Examples
Uses an office corporation analogy, equivalent message-buffer models, nested database subsystems, and a split-brain leadership scenario.
What it assumes
Assumes general software-system familiarity while teaching distributed-system models, terminology, and mental frameworks from first principles.
What you can do after
Evaluate system behavior by separating global guarantees from local observations and by making network, component, and failure assumptions explicit.
How it connects
Connects concurrency, networks, state machines, local knowledge, correctness, safety, liveness, scalability, reliability, replication, and consensus.

Also explained in

Compare how 15 books explain distributed system →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Think Distributed Systems. The section links point to the parts of the book it draws on.