Distributed Systems Core

A distributed system is a group of independent computers that work together but can fail independently. The hard part is not splitting work across them. The hard part is that there is no shared memory, no shared clock, and no guarantee that a message you sent ever arrived. Each node sees its own slightly different view of the world, and the system has to behave correctly anyway.

The lessons here start from the formal models that describe this behavior. A State Machine and a Finite State Machine give you a precise way to reason about what a node can do and which transitions are legal, which matters because most replication and consensus protocols are built on the idea of replicating a state machine across nodes so they all end up in the same state.

From there the category splits into the recurring problems: agreeing on values, ordering events, replicating data, and coordinating transactions. Every topic in this hub is one answer to the question of how independent machines stay correct together when the network and the hardware are working against them.

Replicating data is not a one-time copy. Replicas drift apart because writes land on different nodes at different times, so distributed databases run a constant repair cycle. Gossip Protocol spreads membership and state information node to node, the same way news travels through a crowd, so the cluster knows who is alive without a central registry. Hinted Handoff stores writes meant for a temporarily down node and delivers them when it returns. Read Repair fixes stale data at read time, Anti-Entropy runs background comparisons to reconcile differences, and Sloppy Quorum keeps a system available by accepting writes on backup nodes during a partition. These five together are the machinery that powers Cassandra and DynamoDB style availability.

Coordinating writes across multiple services is the other major theme. Distributed Transactions ask how you commit an operation that touches several databases as a unit. Two-Phase Commit gives you atomicity but blocks if the coordinator dies, and Three-Phase Commit tries to remove that blocking at the cost of more network round trips. The Saga Pattern takes a different route entirely, breaking one big transaction into a sequence of local steps each with a compensating undo, which is the standard approach in microservices where a single locking transaction across services is not realistic.

Finally, the category covers patterns for modeling state itself. CQRS separates the write path from the read path so each can scale and be shaped independently. Event Sourcing stores every change as an immutable event rather than overwriting state, giving you a full audit history and the ability to rebuild state at any point in time. The Actor Model and Reactive Systems round it out with concurrency and resilience patterns for systems that must stay responsive under load and partial failure.