Peer-to-Peer (P2P)
No central server, nodes talk directly to each other. P2P powers file sharing, blockchains, and some distributed systems. Understanding it broadens your architectural vocabulary.
The Concept Explained
Client-server, from the first lesson, is built on an asymmetry: one side holds authority and serves, the other requests. Peer-to-peer removes the asymmetry. Every node is both client and server, requesting resources from others and serving its own.
That single change has a consequence worth stating plainly, because it is what makes P2P interesting rather than merely different: capacity grows with participation. In client-server, every additional client adds load to a fixed server, so growth is a cost. In P2P, every additional peer adds its bandwidth and storage to the pool, so growth adds capacity. A popular file in a P2P network is served faster because it is popular; a popular file on a server is served slower for the same reason.
The defining property is that peers contribute the resources they consume. This inverts the scaling economics: demand brings its own supply. It is why P2P handles flash crowds that would overwhelm a server, and it is the reason the model persists for content distribution despite being harder in almost every other respect.
How It Works
The Discovery Problem
A peer joining the network faces an immediate difficulty. It wants a resource, that resource is held by some other peer, and it has no directory to consult. How does it find out who has what?
Three answers have been used, and the progression between them is the history of the field.
A central directory. Peers register what they hold with an index server, and queries go there. Lookups are fast and exact. It is also not really peer-to-peer in the important sense: the index is a single point of failure and a single point of control, and shutting it down disables the network even though the peers are all still running.
Flooding. No directory at all. A peer asks its neighbours, who ask theirs, out to some hop limit. Fully decentralized and genuinely robust, and it scales badly: query traffic grows sharply with network size, and a limited hop count means rare resources may not be found even though someone has them.
Distributed hash tables. The modern answer. The network collectively implements a hash table, where every key maps deterministically to the peer responsible for it, and lookups take a small number of hops.
How a DHT Finds Things
Each peer takes an identifier from the same space as the keys, typically by hashing its address. A key is the responsibility of the peer whose identifier is closest to it under some distance metric. This should feel familiar: it is consistent hashing from the sibling course, applied to a network of participants rather than to a set of cache nodes.
Locating a Resource Through a Distributed Hash Table
Click each step to explore
The logarithmic hop count is what makes the DHT viable. A million peers resolves in about twenty hops, and ten million in about twenty-three. Doubling the network adds one hop. Compare that with flooding, where traffic grows with network size.
Every real P2P network needs bootstrap nodes, and this is where the pure decentralization story gets complicated. A peer joining has no knowledge of anyone, so it must contact some known address to enter the network. Those addresses are published in the client, and they are a genuine centralized dependency: if every bootstrap node is unreachable, new peers cannot join even though the network is fully healthy. Decentralized systems tend to have a small centralized edge somewhere, and being honest about where it is is more useful than claiming there is none.
What P2P Gives Up
No authority means no easy consistency. With no node holding the truth, agreeing on shared state is genuinely hard. This is why blockchains need elaborate consensus mechanisms: they are solving the problem that client-server solves by having a server.
Peers are untrusted. A server you operate runs your code. A peer runs whatever its owner wants, so it may lie, serve corrupted data, or attempt to disrupt the network. Content addressing, where a resource is identified by the hash of its contents, is the standard defence: you can verify what you received matches what you asked for, regardless of who sent it.
Peers are unreliable and heterogeneous. They leave without warning, sit behind restrictive networks, and vary enormously in bandwidth. Redundancy and connection traversal techniques are mandatory rather than optional.
Free riding. Peers that consume without contributing undermine the model, which is why BitTorrent has a tit-for-tat mechanism favouring peers that upload.
System Design Implications
P2P wins for bulk distribution of large immutable content. The properties align exactly: content that does not change can be verified by hash, popularity brings capacity, and no consistency problem exists because nothing is being mutated. Software and game distribution, video delivery, and large dataset sharing are the natural fits.
It wins where no party should hold authority. Blockchains use it because the absence of a controlling entity is the product requirement, not an implementation choice. The same applies to censorship-resistant systems, where a central point is precisely what an adversary would attack.
It wins for flash crowds. A sudden surge that would overwhelm a server makes a P2P network faster, because every new participant is also a new source.
It is a poor fit for mutable shared state, for anything needing low predictable latency, and for anything requiring an authoritative answer. If a central server is permissible, it is nearly always simpler and better.
Hybrid designs are common and sensible. Content delivery networks with peer-assist serve from edge servers and let clients fetch from each other where available, keeping the guarantees of infrastructure while capturing some of the capacity benefit. Many so-called P2P systems use a tracker or bootstrap infrastructure alongside genuine peer exchange.
The transferable idea is the DHT itself. Consistent hashing, logarithmic routing, and replication across neighbours reappear inside distributed databases and caches, where the peers are servers you control rather than untrusted strangers. Knowing this connects P2P to systems you will actually build.
For the discovery half of the question, name the progression rather than one answer: a central index is simple and reintroduces the single point of failure, flooding is fully decentralized and scales badly, and a DHT gives logarithmic lookups by assigning key responsibility through consistent hashing. Then add the honest caveat about bootstrap nodes, which shows you know where the decentralization actually ends.
Tradeoffs and Decision Framework
| Dimension | Client-server | Peer-to-peer |
|---|---|---|
| Capacity as users grow | Falls, server is fixed | Rises, peers contribute |
| Single point of failure | The server | Bootstrap nodes only |
| Consistency of shared state | Straightforward | Very hard |
| Trust model | Server is trusted | Peers are not |
| Latency | Predictable | Variable, depends on peers |
| Operating cost | Borne by the operator | Distributed across peers |
| Content integrity | Trusted by source | Verified by content hash |
| Best for | Mutable authoritative state | Large immutable content |
The framework in three questions. Is the content immutable, since content addressing and hash verification are what make untrusted peers workable and mutable state is where P2P becomes genuinely hard? Is decentralization a requirement or merely an aesthetic, because if a server is acceptable it is simpler in every dimension except capacity economics? And does the workload have the popularity profile where peer contribution helps, meaning many peers wanting the same large thing at once?
If the answer to the second question is that a server is acceptable, use one. P2P is a substantial increase in complexity that pays off only when its specific properties are needed.
Common Mistakes
Claiming there is no central dependency. Bootstrap nodes are a real centralized edge in every practical P2P network.
Underestimating churn. Peers leave without warning and constantly. Replication and repair are core requirements rather than refinements.
Trusting peer-supplied data. Peers run code you do not control. Content addressing lets you verify what you received rather than trusting who sent it.
Using it for mutable shared state. Without an authority, agreement is a consensus problem, which is why blockchains are as complex as they are.
Ignoring free riding. Without an incentive mechanism, consumption outpaces contribution and the capacity advantage evaporates.
Assuming direct connections always work. Restrictive networks block inbound connections, so traversal techniques and relays are needed in practice.
Expecting predictable latency. Peer quality varies enormously and there is no service level to enforce.
Missing the connection to consistent hashing. A DHT is the same idea applied to a network. Seeing that link is what makes the topic useful beyond file sharing.
Explain the peer-to-peer model. How do peers find each other without a central server, and where is P2P the right architecture?