Networking

Client-Server vs. P2P

Every protocol in this domain — HTTP, MQTT, DNS — assumes one side asks and the other answers. That's a design choice, not a law of networking: this page is about the two fundamental shapes an application's communication can take, and why nearly everything covered so far picked one of them.

Quick reference

What it is: Two opposite architectures for how devices on a network talk to each other — one central authority everyone connects to, or every device talking directly to every other device.
Mental model: Client-server is a restaurant kitchen — one place everyone's order goes through. P2P is a potluck — everyone brings something and shares directly with everyone else, no central kitchen at all.
Key numbers: Client-server scales predictably by adding server capacity; P2P scales its raw capacity automatically as more peers join, at the cost of coordination complexity.
Reach for it when: Deciding whether a system needs one authoritative source of truth (client-server) or can tolerate — or wants — fully decentralized coordination (P2P).

Client-server

One or a small number of servers hold the data and make the decisions; every client talks only to a server, never directly to each other. Nearly every protocol on this domain — HTTP, DNS, SMTP — is built around exactly this shape, because it gives one obvious place to enforce rules, keep data consistent, and control access.

One authority, one place to enforce rules and keep data consistent — and one bottleneck/single point of failure.

Peer-to-peer

No central server at all — every participant (peer) can connect directly to others and exchange data with them, with the responsibility for coordination spread across the peers themselves rather than concentrated in one place.

No single bottleneck and no single point of failure — but also no one place enforcing consistency, which every peer now has to handle cooperatively.

The real tradeoff

	Client-server	Peer-to-peer
Consistency/control	Easy — one authority decides	Hard — peers must agree cooperatively
Single point of failure	Yes — the server	No — inherently redundant
Scaling raw capacity	Requires adding server capacity	Grows automatically as peers join
Simplicity	Simple to reason about and secure	Genuinely harder to design correctly

Real-world applications

Nearly every web/API service — client-server, almost without exception — HTTP itself has no concept of one client talking to another.
BitTorrent — the canonical P2P example — a file is assembled from pieces fetched directly from many other peers simultaneously, rather than one central download server.
Blockchain networks — deliberately peer-to-peer by design, specifically to avoid any single controlling authority over the shared ledger.
IoT mesh device coordination — some smart-home device meshes let devices relay for each other directly rather than every message round-tripping through a central hub.

Gotchas

Field notes

Most "P2P" consumer apps are actually hybrid — a central server for discovery/coordination (finding other peers, authentication) with the bulk data transfer itself happening peer-to-peer; pure P2P with zero central coordination is rarer than the marketing term suggests.
NAT makes true P2P connections genuinely harder — two peers both behind separate home routers often can't simply connect directly to each other without extra coordination (NAT traversal techniques) to punch through both.
Client-server's single point of failure is a real, well-understood risk — but it's also exactly why it's easier to secure, monitor, and reason about; P2P's resilience is not automatically a security or reliability upgrade.