A Catalog of Networking Patterns in Distributed Systems
Distributed systems struggle with a fundamental tension: multiple copies of data must stay synchronized, but processing nodes fail and network delays are unpredictable. The software handling data storage, messaging, and system management typically solves the same set of problems in the same way. These solutions form a catalog of patterns that developers can draw from and combine when building their own distributed infrastructure.
Coordination and Consensus
For a cluster to make progress, nodes must be able to decide on a leader and agree on ordering. Leader and Followers assigns a single server to coordinate replication, while Emergent Leader orders nodes by their age in the cluster so a leader can be chosen without an explicit election. The Generation Clock tracks server generations with a monotonically increasing number, and HeartBeat signals availability by periodically messaging every other server.
When nodes disconnect, safe consensus requires stronger protocols. Paxos relies on two consensus-building phases to reach agreement even under partial failure. Majority Quorum prevents two groups of servers from making independent decisions by demanding a majority for every decision. Consistent Core shrinks this problem by maintaining a smaller, strongly consistent cluster that coordinates server activities for a larger data cluster, avoiding the need for quorum algorithms at scale.
Time is a central challenge in coordinate activities. Lamport Clock uses logical timestamps as versions to order values across servers, and the Hybrid Clock combines a system timestamp with a logical one so versions read as dates and times while remaining orderable. Clock-Bound Wait covers uncertainty in time across cluster nodes before reading or writing so that values can be correctly ordered.
Lease applies a time bound to coordinate how long cluster nodes can act, preventing stale leaders from resuming control. Two-phase decision making between nodes needing an atomic update falls to Two-Phase Commit, which updates resources on multiple nodes in one operation.
Replication and State
Keeping state synchronized usually depends on a Replicated Log, where a write-ahead log is sent to every node in the cluster. The Write-Ahead Log persists state changes as commands in an append-only log, giving durability without forcing data structures to flush to disk. The Segmented Log breaks this log into multiple smaller files to make operational handling easier. High-Water Mark is the log index indicating the last successful replication, and Low-Water Mark marks which portion of the log can be discarded.
Reads and writes often need distinct strategies. Follower Reads serves reads from follower nodes to increase throughput and reduce latency. Each update to a value can be stored as a new Versioned Value, preserving the ability to read historical state. Conflicts from concurrent changes to the same data across nodes are handled with a Version Vector, a per-node list of counters. The Idempotent Receiver identifies client requests uniquely so duplicates caused by client retries are ignored.
Clients are kept in sync with the server through State Watch, which notifies them when a specific value changes.
Data Placement and Resource Use
Scaling storage requires deliberate data layout. Fixed Partitions keeps the number of partitions constant so that the mapping of data to partitions remains stable as the cluster grows. For range queries, Key-Range Partitions orders data in sorted key ranges.
Network and processing efficiency both shape performance. Single-Socket Channel uses one TCP connection to maintain the order of requests sent to a server. Request Pipeline sends multiple requests without waiting for each response, improving latency, and Request Batch combines many requests to better use the network. Once responses arrive, the Request Waiting List tracks client requests that only qualify for a response once criteria are met — typically when other cluster nodes have answered. Singular Update Queue processes requests asynchronously with a single thread so order is preserved without blocking the caller.
Gossip Dissemination spreads information efficiently by having each node pass it to a random selection of other nodes, ensuring the whole cluster learns it without flooding the network.
