Skip to main content

Peer-to-Peer Architecture

Peer-to-peer (P2P) architecture removes the central authority Client-Server Architecture is built around entirely: there's no server, only peers — nodes that are simultaneously clients and servers to each other, requesting resources from some peers while providing resources to others, with no single node that everyone else depends on.

No central authority means no central bottleneck — or single point of failure​

The direct payoff of removing a server is removing the Single Point of Failure that comes with one: there's no one machine whose outage takes the whole system down, and no central infrastructure that has to be scaled to handle everyone's traffic — every peer that joins brings its own resources (bandwidth, storage, compute) with it, so the network's total capacity grows automatically as it grows, rather than requiring a central operator to keep provisioning more server capacity.

System Design Lab

The problem P2P has to solve that client-server gets for free​

Removing the server doesn't remove the underlying problems it was solving — it just means the network of peers has to solve them without any central coordinator:

  • Finding anything. In client-server, a client just asks the server. In P2P, "which peer(s) actually have this piece of data" has no default answer — this is solved with a Distributed Hash Table (DHT), which assigns responsibility for a piece of data to specific peers using the same Consistent Hashing idea already covered for distributing keys across cache or database nodes, just applied across an open, changing population of peers instead of a fixed cluster.
  • Knowing who's still around. Peers join and leave constantly, with no central registry tracking membership — the decentralized answer to this is the same Gossip Protocol approach covered for cluster membership in general: peers periodically share what they know about who else is in the network, and that information spreads peer-to-peer without any central coordinator needing to track it.
  • Trusting data that came from an untrusted peer. A client trusts a server because it's a known, accountable operator; a peer has no such guarantee about a stranger's data. Content is commonly verified with a cryptographic hash — the same integrity idea covered in Checksums, just using the stronger, tamper-resistant variant appropriate for data received from an untrusted source rather than the cheap kind meant only to catch accidental corruption.

Where it's actually used​

BitTorrent is the canonical example: a file is split into pieces, and peers download different pieces from different other peers simultaneously (and upload pieces they already have to others at the same time), so a popular file gets faster to download as more peers join, not slower — the opposite of a central server, which gets more strained as more clients show up. Blockchain networks and some real-time communication tools (early Skype) are other well-known examples, each using P2P specifically to avoid a central operator being a bottleneck, a single point of failure, or a single point of control.

Why this isn't the default choice​

P2P solves real problems client-server doesn't have to (discovery, membership, trust), and that's exactly why it isn't the default: most systems have an obvious central authority already (a company running the service), and building peer discovery, gossip-based membership, and trustless verification is meaningfully more complex than "the client asks the server." P2P earns its complexity specifically when there's no natural central authority, when the goal is explicitly to avoid one (censorship resistance, no single company controlling the network), or when spreading load across participants' own resources is itself the point (as in BitTorrent, where the network gets faster as it grows precisely because there's no central server to bottleneck on).

Why this matters in an interview​

P2P is rarely the right default answer, and naming it as an option should come with a specific reason a central server genuinely doesn't fit — no natural authority, a deliberate goal of decentralization, or wanting capacity to scale with participants rather than with a central operator's own infrastructure. Being ready to name the DHT/gossip/trust problems P2P has to solve (that client-server gets for free) shows the tradeoff is genuinely understood, not just the buzzword.

Peer-to-peer vs. client-server: pros and cons​

Pros

  • No single point of failure — no one server's outage takes down the network
  • Capacity grows automatically as more peers join, with no central infrastructure to scale
  • No single operator that has to be trusted, funded, or targeted to disrupt the system

Cons

  • Discovery, membership, and trust all need their own decentralized solutions
  • Harder to enforce consistent access control or a single authoritative version of data
  • Debugging and monitoring have no single vantage point to observe the whole system from

Further Reading​

Saved locally in your browser — visible in the sidebar as you go.