Gossip Protocol

A gossip protocol (or epidemic protocol) is a decentralized communication method where nodes in a distributed system randomly share information with a few peers at regular intervals. Like a rumor spreading through a crowd, the information propagates exponentially fast until all nodes agree on the cluster state, without needing a central coordinator.

Gossip protocols are primarily used for cluster membership (knowing who is alive or dead) and state synchronization (distributing configuration changes) in masterless architectures.

• Periodic Exchange: Every second, node A picks a random node B and sends it its current view of the cluster state (including a version number or timestamp for each piece of data).
• Reconciliation: Node B compares A's state with its own. If A has newer information about a node, B updates its local state. If B has newer info, it sends it back to A.
• Exponential Spread: Because every node is doing this simultaneously, an update (like a node crashing) spreads to O(log N) nodes in each round, reaching the entire cluster extremely quickly.

Failure Detection

Instead of a central master pinging every node (which bottlenecks at scale), nodes monitor each other. If node A stops gossiping, the nodes that usually talk to it mark it as "suspicious." If no one hears from node A after a certain time, the gossip changes to "Node A is dead," and that fact propagates through the cluster.

Gossip protocols are incredibly resilient and scale beautifully because the network load per node remains constant regardless of the total cluster size. However, the consistency is strictly eventual. It takes time for the rumor to spread, meaning for a few seconds, different nodes might have different views of the cluster. Furthermore, gossiping generates continuous background network chatter, even when the cluster is perfectly healthy and stable.

• Mention Cassandra or Amazon Dynamo; they are the classic examples of masterless architectures that rely heavily on gossip for cluster membership.
• Contrast it with a master-slave architecture. Gossip is how you avoid having a single master node managing the cluster state.
• If asked how to handle conflicts (e.g., two nodes report different states for a third node), mention that gossip pairs well with Vector Clocks or simple Last-Write-Wins timestamps to resolve divergent states.