You are viewing a free preview of this lesson.
Subscribe to unlock all 10 lessons in this course and every other course on LearningBro.
When devices are networked together, the way responsibility is distributed among them defines the network's architecture. The central question is: does one machine hold the resources and authority while the others ask it for things, or are all machines equal partners that share directly? These two answers — client-server and peer-to-peer (P2P) — are the two fundamental network models, and almost every networked system you use is one, the other, or a deliberate blend of both.
At A-Level you must understand both models and be able to compare them across architecture, management, security, scalability, cost and resilience. You must also distinguish thin from thick (fat) clients and, most importantly, justify which model suits a given scenario. Comparison and justification — weighing the trade-offs against a scenario's actual needs — not mere description, are where the marks lie. Throughout, keep one idea central: the choice is fundamentally about centralising control (gaining security and manageability at the cost of expense and a single point of failure) versus distributing it (gaining cheapness and resilience at the cost of weaker control).
This lesson addresses the Communication and networking area of the AQA A-Level Computer Science (7517) specification, specifically network architecture: the client-server and peer-to-peer models, their characteristics, relative advantages and disadvantages, the distinction between thin- and thick-client computing, and the selection of an appropriate model for a given situation. It connects to the network protocols content (HTTP, SMTP and the like are client-server protocols) and to network security and the cloud.
Note that this is a question of logical architecture — how roles and responsibilities are arranged — rather than of physical topology (the shape of the cabling). The same physical network of cables and switches can run a client-server arrangement or a peer-to-peer one depending purely on how the software on the machines behaves. Keeping architecture and topology separate in your mind avoids a common source of confusion in exam answers.
In the client-server model a dedicated, always-on server provides services or resources, and clients (the end-user devices) request them. Responsibility is centralised on the server. The relationship is unequal by design: the server is the authoritative provider and the clients are consumers, which is precisely what gives this model its central control and its central point of weakness.
flowchart LR
C1["Client"] --> S["Server"]
C2["Client"] --> S
C3["Client"] --> S
S --> C1
S --> C2
S --> C3
| Component | Role |
|---|---|
| Server | Stores and manages shared resources (files, databases, applications); authenticates users; enforces security policy; logs activity |
| Client | Requests services from the server and presents results to the user |
In every case the pattern is identical: a dedicated provider holds the shared resource and enforces the rules, and many requesters come to it. This is why so many of the application-layer protocols studied earlier (HTTP, SMTP, FTP) are client-server protocols — they are the concrete realisation of this architecture.
| Advantage | Explanation |
|---|---|
| Centralised management | Data, accounts, security and software are administered in one place |
| Stronger security | The server enforces authentication and access control; patches and policies are applied centrally |
| Easy backups | Central data is straightforward to back up and recover |
| Controlled scalability | The server can be upgraded, or more servers added behind a load balancer |
| Reliable hardware | Servers use redundant, professional-grade hardware (RAID, dual power supplies) |
| Disadvantage | Explanation |
|---|---|
| Single point of failure | If the server fails, all clients lose the service (mitigated, at cost, by redundancy) |
| Cost | Server hardware, software licences and skilled administration are expensive |
| Expertise required | A trained administrator is needed to run and secure the server |
| Bottleneck under load | All traffic converges on the server, which can become overwhelmed at peak demand |
Because every request flows through the server, growth must be planned. Two strategies exist, and naming them strengthens an answer:
flowchart TB
C1["Client"] --> LB["Load balancer"]
C2["Client"] --> LB
C3["Client"] --> LB
LB --> S1["Server 1"]
LB --> S2["Server 2"]
LB --> S3["Server 3"]
Horizontal scaling with a load balancer is how large web services handle millions of users while keeping the logical client-server model intact — the clients still see "a server", unaware that many machines sit behind it. It also softens the single-point-of-failure weakness, which is the standard mitigation an examiner expects you to mention.
In a peer-to-peer network there is no central server. Every device — a peer — is equal and acts as both client and server, sharing and consuming resources directly with other peers.
flowchart TB
P1["Peer"] <--> P2["Peer"]
P1 <--> P3["Peer"]
P2 <--> P3
P3 <--> P4["Peer"]
P1 <--> P4
The recurring theme across these examples is that P2P shines wherever no single entity should (or can afford to) be the central provider — whether for scaling reasons (file distribution), trust reasons (blockchain), latency reasons (media streams) or cost reasons (the tiny office). Where any of those pressures dominate, distributing the work across equal peers is the natural fit.
The scaling behaviour of P2P is the opposite of a single server, and understanding why is worth real marks. Consider distributing one large file:
// Single server: capacity is FIXED and SHARED
// 100 downloaders share the server's upload bandwidth ->
// each gets ~1/100th -> the more users, the SLOWER everyone goes,
// and a sudden surge can overwhelm or crash the server.
// BitTorrent (P2P): capacity GROWS with demand
// The file is split into many small pieces.
// Each downloader, as soon as it has a piece, UPLOADS that piece
// to others. So every new downloader is also a new SOURCE.
// 100 downloaders => ~100 extra uploaders => total capacity rises
// roughly in step with demand. Popularity HELPS rather than hurts.
This is why P2P is the natural choice for distributing a popular file (a Linux distribution, a game update) to millions cheaply: the network heals and grows under load instead of buckling. The cost is borne collectively by the peers' own bandwidth, so the publisher needs no expensive server farm. The flip side — explored below — is the loss of central control and security.
| Advantage | Explanation |
|---|---|
| Low cost | No dedicated server hardware or licences |
| Simple to set up | Little specialist administration for a small network |
| No single point of failure | If one peer goes offline, the others carry on |
| Bandwidth scales with peers | Each new peer contributes its own upload capacity — ideal for distributing popular files |
| Disadvantage | Explanation |
|---|---|
| Weak, inconsistent security | Each user secures their own machine; there is no central enforcement |
| No central management | No centralised backups, accounts or policy |
| Variable performance | Peers differ in hardware and bandwidth; slow peers drag on shared performance, and a resource is unavailable if every peer holding it is offline |
| Hard to control content | Difficult to audit or restrict what is shared — a real concern for file-sharing networks |
Within the client-server model, how much work the client does versus the server defines the client type — a distinction the specification names explicitly. It is, in effect, a second centralise-versus-distribute decision, this time about where the processing happens rather than where the resources live.
A thin client has minimal local processing and storage and depends heavily on the server, which performs most computation and holds the data and applications. A thick (fat) client does substantial processing locally and can often function with little or no server contact. The choice mirrors the wider model's trade-off in miniature: thin clients centralise processing (cheap, manageable, but server- and network-dependent), whereas thick clients distribute it (resilient and capable offline, but costlier and harder to keep consistent).
| Aspect | Thin client | Thick (fat) client |
|---|---|---|
| Local processing | Minimal — done on the server | Substantial — done locally |
| Local storage | Little or none | Significant |
| Reliance on network/server | High — largely useless offline | Low — works offline |
| Hardware cost per device | Low (cheap, simple devices) | Higher (capable hardware) |
| Central management/updates | Easy — update once on the server | Harder — update every device |
| Example | Browser-based terminal, point-of-sale screen | Standalone PC running local software, modern games console |
Trade-off: thin clients are cheap to buy and easy to manage centrally but lean entirely on a reliable server and network; thick clients are resilient and powerful offline but cost more per device and are harder to keep updated and consistent.
A worked judgement. Consider a call centre with 200 identical workstations all running the same customer-service web application. A thin-client approach is compelling: the workstations can be cheap, the application and data live on the server so an update is applied once centrally, security and backups are centralised, and a broken device is trivially swapped because it holds nothing of value. The risks — total dependence on the server and the local network — are acceptable because the call centre already has a reliable, well-managed internal network and the work cannot happen offline anyway. Now contrast a field engineer who must run design software on a laptop at remote sites with no connectivity: here a thick client is essential, because the device must do the heavy processing locally and function entirely offline; the higher per-device cost and the harder update logistics are simply the price of that independence. The same trade-off analysis, applied to different requirements, points to opposite answers — exactly the reasoning examiners reward.
The modern incarnation of thin-client computing is the web browser itself: when you use a web-based email or document editor, your browser is a thin client and the heavy lifting happens on cloud servers. Cloud computing is, at heart, the client-server model operated at vast scale, which is why these ideas remain highly relevant rather than historical.
| Feature | Client-Server | Peer-to-Peer |
|---|---|---|
| Central server | Yes | No |
| Management | Centralised | Decentralised |
| Security | Stronger (central enforcement) | Weaker (each peer self-manages) |
| Cost | Higher (server, admin, licences) | Lower (no dedicated server) |
| Single point of failure | Yes (the server) | No (distributed) |
| Scalability | Server can bottleneck under load | Scales well — peers add bandwidth |
| Backups | Centralised and easy | Decentralised and difficult |
| Typical use | Business networks, web/email services, schools | File distribution, small ad-hoc networks, blockchain |
Subscribe to continue reading
Get full access to this lesson and all 10 lessons in this course.