4.9.4.11 - Thin-client and thick-client computing
Learn how the location of processing and storage distinguishes thin and thick clients, and how network dependence, management and workload affect the choice between them.
Where processing and storage happen
Thin-client and thick-client computing differ chiefly in how much application work the client performs locally.
A thin client relies heavily on a server for application processing and often for application/data storage. The client supplies input and displays the returned output. In a remote desktop arrangement, the server executes the application while the client sends keyboard/mouse actions and displays screen updates. The client still performs some work, such as handling its network connection and decoding the display; “thin” does not mean no processor or memory.
A thick client (also called a fat client) performs a substantial amount of application processing locally and normally has enough processing power, memory and local software for that work. It may keep local application/data files, while still using servers for shared data, authentication, synchronisation or other services. A desktop photo editor can process an image locally even when its output is later uploaded to shared storage.
Client thickness
The degree to which application processing and supporting resources are provided locally by the client rather than centrally by a server.
Do not classify a machine solely by its size, price or whether it uses a browser. A browser application can perform substantial local JavaScript processing, while a powerful laptop may act as a thin remote-desktop terminal for one application. The relevant question is where the particular workload runs. Also distinguish this from peer-to-peer: thin and thick clients can both operate within a client-server system.
| Aspect | Typical thin-client arrangement | Typical thick-client arrangement |
|---|---|---|
| Main application processing | On server | Mainly on client |
| Local hardware demands | Lower for the application | Higher for local computation |
| Application installation/storage | Mainly central | Often local, possibly with shared server data |
| Server role | Executes application and supplies output | Supplies services/data while client executes substantial work |
Network and management consequences
Moving processing to a central server changes both the system's network needs and where administrators manage it.
Thin clients need dependable access to the server for the application to remain useful. A failed connection can prevent further work, and high latency can delay the response to input. Bandwidth requirements depend on the traffic: a text terminal can use little data, while rapidly changing high-resolution remote displays can demand much more. A thin client does not automatically use less bandwidth than a thick client.
The server must provide enough processing, memory and storage for simultaneous users. Underprovisioning can make every session slow; server failure can interrupt many users at once. Redundant servers and network paths can reduce this risk, but increase cost and complexity. The endpoint hardware may be inexpensive, yet the complete system also includes server capacity and the network.
Central application installation, updates and backups can simplify management: administrators change a centrally hosted application instead of updating every local installation. Data kept centrally can reduce sensitive local copies and simplify recovery. This does not remove security duties. Access controls and endpoint protection are still needed, and compromise of a central service can affect many users.
Thick clients can continue suitable local work when disconnected, provided required software, licences and data are available locally. They distribute computational load across client machines and can avoid continuous screen-update traffic. They require more capable endpoints and management of local installations, patches and files. Local copies may be lost or become inconsistent; synchronisation and backup policy matter. A thick client still fails if the task depends on an unavailable server, such as fetching a record it has not cached.
Choosing a client model for a workload
A good client choice follows the workload and operating conditions rather than a claim that one model is always better.
First establish where computation must happen and what data the task needs. Then consider connectivity and latency, concurrent user numbers, endpoint and server capacity, management, security and total cost. A useful justification connects an actual requirement to a consequence of the architecture.
A library offering a standard centrally managed catalogue application on a reliable local network may suit thin clients. Modest endpoints can access the shared service; central updates and backups simplify administration. The server must support busy periods, and service/network resilience matters because many terminals depend on it.
Fieldworkers editing large photographs where connections are unreliable may suit thick clients. Local processing and local files permit offline edits and avoid transferring each display interaction. The organisation must provide capable hardware, protect/backup local data and synchronise work when connectivity returns. A cloud-only photo application would not provide that offline benefit merely because it is opened on a powerful laptop.
Workloads can combine both arrangements. An architect may locally render a model using a thick-client application while connecting to a central database; the same device can use a thin-client remote application for another task. State which application is being considered. In a comparison, name both sides of the trade-off: cheap endpoints do not establish a cheaper complete thin-client system, and a fast local processor does not overcome inaccessible essential server data.