The model
In peer-to-peer architecture there is no privileged server. Every node offers resources (bandwidth, storage, compute) and consumes them from others. Nodes join and leave constantly — churn is the normal state, not an incident — so the protocol, not an operator, must handle membership, routing and repair.
Three properties fall out of that:
- Capacity scales with demand. Each new participant adds upload bandwidth and storage. Popular content gets faster instead of overloading an origin.
- No single point of failure and, often more importantly, no single point of control or censorship.
- Everything is harder. Consistency, security, discovery and debugging all become distributed problems with no authority to arbitrate.
Pure, hybrid and structured
| Type | How peers find data | Example | Weakness |
|---|---|---|---|
| Unstructured, flooding | Broadcast queries to neighbours, TTL-limited | Early Gnutella | Query traffic explodes; rare content is unfindable |
| Hybrid (super-peers / trackers) | A directory or tracker maps content to peers | BitTorrent with trackers, Skype's original design | The directory is a central weak point |
| Structured (DHT) | Deterministic key-based routing | Kademlia (BitTorrent DHT, IPFS, Ethereum discovery) | Churn cost, complexity, weak to Sybil attacks |
| Broadcast/consensus | Every node holds the whole log | Blockchains | Throughput bounded by the slowest participant class |
Most real systems are hybrids. BitTorrent uses trackers and a DHT and peer exchange, because each mechanism fails differently.
DHTs: routing without a directory
A distributed hash table gives every node and every key an ID in the same address space. A key is stored on the nodes whose IDs are closest to it. Lookups route greedily toward the target, halving distance each hop, so any key is found in O(log N) hops while each node keeps only O(log N) contacts.
id space: 160-bit; distance(a,b) = a XOR b
routing table = k-buckets, one per distance range,
each holding up to k (=20) live contacts
FIND_VALUE(key):
candidates = alpha closest known nodes to key
loop:
query them in parallel
each returns the value, or the closest nodes IT knows
keep the k closest seen so far
until no closer node is returned
storage: replicate the value on the k closest nodes,
republish periodically to survive churnThe elegance is that routing tables self-heal: every query teaches a node about live peers. The cost is that churn constantly invalidates contacts, so a DHT is always doing background maintenance.
Discovery and NAT traversal
Two peers behind home routers cannot simply connect — this is where most P2P engineering time actually goes.
- Bootstrap. A new node needs at least one known peer: hardcoded bootstrap nodes, DNS seeds, or local multicast discovery.
- STUN. A peer asks a public server "what does my address look like from outside?" to learn its NAT mapping.
- Hole punching. Both peers send packets simultaneously via a signalling channel so each NAT sees outbound traffic and permits the reply. Works for most NAT types.
- TURN relay. When hole punching fails (symmetric NATs, strict corporate firewalls), traffic relays through a server. Roughly 10–20% of connections in the wild need this — so a "serverless" P2P product still runs servers.
Trust: peers can lie
- Content integrity: address data by its hash. If the hash matches, the content is correct regardless of who served it. This is why BitTorrent hashes every piece and IPFS uses content-addressed CIDs.
- Identity: public keys as node IDs; messages signed. Otherwise a peer can impersonate any other.
- Sybil attacks: one adversary spawns thousands of identities to control a region of the keyspace. Mitigations: bind IDs to a scarce resource (proof of work, stake, IP diversity constraints), and replicate across the k closest nodes.
- Eclipse attacks: surround a victim with malicious peers so it sees a false view. Mitigate with diverse, long-lived contacts and multiple bootstrap paths.
Incentives and free riding
A P2P system where everyone downloads and nobody uploads collapses. Protocols therefore encode incentives directly:
- Tit-for-tat (BitTorrent): a peer preferentially uploads to peers that upload to it, with periodic optimistic unchoking so newcomers can bootstrap.
- Rarest-first piece selection, which keeps the swarm healthy by spreading scarce pieces before common ones.
- Economic incentives (block rewards, storage proofs) in blockchain and decentralised-storage networks.
Real systems
| System | P2P mechanism | Why P2P |
|---|---|---|
| BitTorrent | Swarm + tracker + DHT + tit-for-tat | Distribution cost scales with popularity |
| IPFS | Kademlia DHT + content addressing | Location-independent, verifiable content |
| Bitcoin / Ethereum | Gossip broadcast + consensus | No trusted operator permitted |
| WebRTC calls | Signalling + STUN/TURN, direct media | Lowest latency, no media server cost |
| Cassandra / Dynamo | Gossip + consistent hashing ring | No coordinator node to fail |
| Large-scale CDN prefetch | Peer-assisted edge delivery | Cuts origin bandwidth during spikes |
The last two matter for interviews: several "server" systems are internally P2P. Cassandra has no master precisely so any node can fail without a leader election.
Interview framing
Strong answer
"For a global software-update rollout, origin bandwidth is the ceiling, so I'd make distribution peer-assisted: chunk the artifact, hash every chunk and sign the manifest so peers cannot serve corrupted data, discover peers within the same network segment first to keep traffic local, and fall back to the CDN when no peer has the chunk. I still need centralised bootstrap and signalling, plus a relay for peers behind symmetric NAT. Incentives are not an issue inside one organisation, but Sybil protection matters if this is public, so node identities are certificate-bound."
Follow-ups
- How does a new node join safely?
- What stops a peer serving tampered data?
- Why is a DHT lookup O(log N), and what breaks under heavy churn?