Client-server
In a client-server system, devices (clients) send requests to a server, and the server answers. Almost every app on a phone works this way: the app is a client, and the data lives on servers in a data centre. Clients rarely talk to each other directly. When two people message each other, each phone talks to the server, and the server passes the message along.
The model is popular for good reasons. There is one place to store data, apply rules, check permissions, and fix bugs. The server is the source of truth, so there is no question of which copy is right.
What it depends on is a working path from every client to the server, all the time. If the server goes down, or a device loses its connection, that device can no longer do anything that needs the server, even if the person it wants to reach is standing next to it.
Peer-to-peer
In peer-to-peer (P2P) systems, devices talk to each other directly as equals. Each one can both ask and answer. File-sharing networks, video calls that connect browsers directly, and phones exchanging data over Bluetooth are all peer-to-peer.
Peer-to-peer describes the relationship between devices, not the link they use. Two computers can be peers across the internet, in which case they still depend on internet infrastructure to reach each other. Two phones can also be peers over a direct radio link, such as Bluetooth Low Energy or Wi-Fi Direct on Android, in which case they need no infrastructure at all. Only the second kind keeps working when the internet is gone.
The limit of plain peer-to-peer is reach. Over a direct link, a device can only talk to devices within its own radio range.
Mesh
A mesh is peer-to-peer with relaying. Each device talks directly to its neighbours, and also forwards messages for others, so a message can reach a device several hops away. That removes the range limit of a single direct link and removes the dependency on a central server. The cost is the work of routing: discovering neighbours, choosing paths, stopping loops, and retrying lost messages, all on devices that move and run on batteries.
Side by side
| Client-server | Peer-to-peer | Mesh | |
|---|---|---|---|
| Who talks to whom | Every client to the server | Devices directly, as equals | Devices directly, and through each other |
| Where the data lives | On the server | On the devices | On the devices |
| If the server or internet fails | Clients stop working together | Direct links keep working | Direct and relayed paths keep working |
| Reach | Anywhere the internet reaches | One link’s range, unless over the internet | Many hops, as far as the devices extend |
| Main cost | Running servers and connectivity | Finding and connecting to peers | Routing, battery, and airtime |
How real systems combine them
Very few systems are purely one shape. A messaging app can use its server when it is reachable and fall back to direct links when it is not. A mesh can include a gateway device that has an internet connection and passes data to and from a server. A server can stay the system of record while devices exchange work locally and report back later.
When choosing, three questions settle most cases:
- Where is the source of truth? If one server must decide, devices can still work locally, but they need a way to hand their results back and to handle being told no.
- What must keep working without the internet? Anything on that list needs a direct or relayed path between devices.
- How far apart are the devices? Within one radio range, direct peer-to-peer may be enough. Across a building, a site, or a moving fleet, relaying starts to matter.