When you have a cluster of 1,000 nodes and one of them learns something new — a node died, a config changed, a key was added — how do you tell everyone else? The naive answer is broadcast: have the originator tell all 999 others. That works at 10 nodes. At 1,000 it melts your network, and the originator becomes a single point of failure during the broadcast.

Gossip protocols (also called epidemic protocols) borrow from how rumors actually spread among humans. Each node periodically picks a small random subset of peers — typically 1 to 3 — and shares what it knows. Those peers do the same on their next tick. Information spreads exponentially without anyone coordinating it.

The math is the punchline. If each node gossips to f peers per round, the number of informed nodes roughly multiplies by (1 + f) each round. With f=3 and 10,000 nodes, full propagation takes about log₄(10000) ≈ 7 rounds. At a 1-second gossip interval, the entire cluster knows within 7 seconds. Bandwidth per node stays constant regardless of cluster size — that's the magic.

Real-world example: Cassandra. Every Cassandra node runs a gossip task once per second. It picks one random live peer, one random unreachable peer (to detect recovery), and occasionally one seed node. They exchange version vectors of what each knows about every other node — schema versions, load, status, tokens. New nodes joining the ring are discovered organically; failed nodes are marked down by the failure detector that piggybacks on gossip silence. No central registry, no coordinator, no leader election needed for membership.

Other production users: Consul, Serf, Riak, Redis Cluster, and Amazon's DynamoDB internals all gossip for membership and failure detection.

The tradeoffs are real. Gossip is eventually consistent — there's a window where some nodes know and others don't. It's also chatty: a 1,000-node cluster doing per-second gossip generates 1,000 messages per second cluster-wide, even when nothing changes. You need anti-entropy mechanisms (Merkle trees in Cassandra, version vectors elsewhere) to reconcile when nodes disagree about old data, not just new data. And gossip is terrible for ordering — if you need "A happened before B," use a log, not gossip.

Rule of thumb: use gossip when you need scalable membership, failure detection, or best-effort state dissemination across hundreds-to-thousands of nodes. Don't use it for anything that needs strong consistency, ordering, or low-latency propagation to a specific target.