A distributed system is software whose parts communicate over a network. Once software is distributed, messages may arrive late, out of order, more than once, or not at all, making change over time difficult to reason about. A practical response is to move as much logic as possible into data and calculations, isolating the time-dependent actions that need careful handling. section 1.23 section 14.24
Keep these three rules in mind when designing or debugging distributed behavior:
- Assume messages can arrive out of order. section 1.23
- Assume each message may arrive zero, one, or multiple times. section 1.23
- Treat silence as ambiguous: if no response arrives, you cannot know what happened. section 1.23
- Coordinate timelines explicitly instead of relying on usual action durations or lucky ordering. section 2.15
A dinner rush exposes timing bugs
Imagine separate timelines preparing dough, sauce, and cheese. The dough may not be ready while the other timelines continue, and the sauce may not always take the longest. A timeline diagram can reveal that the cheese might arrive too late—an edge case that quiet tests may miss but production traffic can make common. section 2.15
Use the timeline figure to inspect independent activities, identify unsafe ordering, and locate coordination problems before they become production failures. section 2.15
Functional design does not remove distributed-system problems; it isolates them in actions and gives them focused tools. Immutable data, calculations, higher-order functions, and timeline reasoning reduce the amount of code exposed to uncertain timing. section 1.23 section 19.2
