Peer-to-Peer Architecture
Decentralized systems: P2P topology, DHTs, gossip protocols, BitTorrent-style distribution, and blockchain's architectural foundation.
Client-Server vs Peer-to-Peer
In the conventional client-server model, clients request resources and servers provide them. Servers are always-on, centrally managed, and hold the canonical data. This model is simple, easy to secure, and easy to reason about — but it creates bottlenecks: if the server fails or is overloaded, all clients are affected.
In Peer-to-Peer (P2P) architecture, every node acts as both a client and a server. Nodes share resources (bandwidth, storage, compute) directly with each other without a central coordinator. This eliminates single points of failure and allows the system's capacity to grow automatically as nodes join — each new peer brings resources as well as consuming them.
P2P Topology Types
| Topology | Description | Example |
|---|---|---|
| Unstructured P2P | Peers connect randomly; discovery by flooding or gossip | Early Gnutella, Freenet |
| Structured P2P (DHT) | Peers arranged by a consistent hash ring; lookups are O(log N) | Chord, Kademlia (used by BitTorrent, IPFS) |
| Hybrid P2P | Central server for discovery/coordination; direct peer transfer | Napster (original), Skype (historically) |
Distributed Hash Tables (DHTs)
A Distributed Hash Table (DHT) is the key data structure enabling structured P2P. It provides a key-value lookup service distributed across all nodes. Each node is responsible for a range of keys. Lookups for a key route through O(log N) hops, where N is the number of nodes. Kademlia is the most widely deployed DHT — it powers BitTorrent's peer discovery and IPFS.
// Kademlia DHT lookup (simplified)
// Each node has a 160-bit ID. XOR distance determines routing.
function lookup(targetKey):
candidates = kBucket.getClosestNodes(targetKey, k=20)
loop:
query each candidate: "who do you know closest to targetKey?"
newCandidates = merge results
if no closer nodes found:
return closest known nodes to targetKey
candidates = newCandidates
// Each hop brings you closer to the target node.
// O(log N) hops in a network of N nodes.Gossip Protocols
Gossip protocols (also called epidemic protocols) are a communication mechanism used in P2P and distributed systems for propagating information. Each node periodically selects a random set of neighbors and shares its state. Like a rumor spreading through a crowd, information propagates exponentially fast without any central coordinator. Cassandra uses gossip for cluster membership and failure detection; AWS DynamoDB uses it for ring membership.
BitTorrent: P2P File Distribution
BitTorrent is the most successful P2P file distribution protocol. A file is split into chunks; peers download chunks from multiple sources simultaneously and upload chunks they have to others. As a file becomes more popular, more peers have chunks to share — the system's bandwidth increases with demand (unlike client-server where more demand degrades service).
Facebook's P2P Deployment Tool
Facebook (now Meta) used a BitTorrent-based internal tool called 'BitTorrent on HDFS' (and later 'Conveyor') to distribute OS images and application binaries to hundreds of thousands of servers during deployments. Instead of a single file server becoming a bottleneck, servers shared deployment packages with each other, completing cluster-wide deployments in minutes instead of hours.
Blockchain as P2P Architecture
Blockchain is built on a P2P foundation. Every node in a Bitcoin or Ethereum network holds a full copy of the ledger. Transactions are gossiped across the peer network; consensus (Proof of Work, Proof of Stake) determines which transactions are accepted without a central authority. The architectural properties — decentralization, censorship resistance, Byzantine fault tolerance — flow directly from the P2P substrate.
Trade-offs of P2P
| P2P Advantage | P2P Disadvantage |
|---|---|
| No single point of failure | Complex to reason about consistency |
| Scales with participation (bandwidth grows with users) | Security and trust are hard (Sybil attacks) |
| Resilient to censorship and central control | Difficult to implement reliable content moderation |
| Eliminates central server costs | Performance is unpredictable (depends on peer availability and quality) |
| Self-healing network topology | Debugging and monitoring are significantly harder |
Interview Tip
P2P architecture rarely comes up as the primary design choice in interviews — most production systems use client-server. However, it appears in: CDN design (peers caching and sharing content), distributed database internals (gossip for cluster membership in Cassandra, Dynamo), and any question about decentralized or censorship-resistant systems. Know the key concepts: DHT for structured lookup, gossip for propagation, and the fundamental trade-off between decentralization and consistency/control.