Question 5 of 8: Distributed Software Systems

Question 5: Distributed Software Systems (a) 5, (b) 5, (c) 10 — 20 marks

Question text not reproduced: the examination questions are © Engineers and Geoscientists BC. Open the official past paper (linked at the top of this page) to read the question, then follow the worked solution below.

(a) Scalability of Distributed vs. Centralized Systems

A centralized system's capacity is bounded by the resources (CPU, memory, I/O bandwidth) of the single machine it runs on: once that machine is saturated, the only way to grow capacity is vertical scaling — buying a bigger machine — which has a hard physical and economic ceiling. A distributed system instead scales horizontally: additional demand is met by adding more processing nodes, each contributing its own CPU, memory and I/O capacity, so total system capacity grows roughly in proportion to the number of nodes rather than being capped by any single machine's limits. This is why distributed systems are described as inherently more scalable — the scaling strategy itself (add nodes) has no equivalent hard ceiling the way "buy an even bigger single machine" eventually does.

The likely limits on distributed scalability are not physical capacity but coordination costs: network bandwidth and latency between nodes (which do not improve just by adding more nodes, and often worsen as more nodes must communicate), the overhead of maintaining consistency across replicated or partitioned data (locking, consensus protocols), and the increasing complexity of partitioning work and data across nodes without creating hot spots or excessive cross-node traffic. In practice, the fraction of the workload that is inherently sequential or requires cross-node coordination (rather than being embarrassingly parallel) sets the effective ceiling on how much adding further nodes actually helps.

(b) Fat-Client vs. Thin-Client

A fat-client (thick-client) architecture puts significant application logic — data validation, business rules, even a substantial part of data management — on the client machine, with the server providing mainly data storage and access; the classic example is a traditional desktop application talking to a database server. A thin-client architecture keeps the client responsible for presentation only (rendering the UI and forwarding user input), with essentially all application logic and data management executed on the server; the classic examples are a browser-based web application or an old-style terminal talking to a mainframe.

Fat clients give better responsiveness (logic executes locally, no round-trip needed for every interaction) and can continue limited operation when disconnected from the server, but are harder to deploy and update (every client machine needs the new logic installed) and place processing demand on end-user hardware. Thin clients are trivial to update (a single server-side change reaches every user immediately) and impose minimal requirements on client hardware, but depend entirely on network connectivity and place all processing load on the server, which must then be scaled to handle every client's logic centrally.

(c) Distributed-Object Architecture for a National Theatre Booking System

Modelling each theatre's seat inventory as its own remote object (rather than one shared, centralized database of every seat in the country) lets each venue's booking system remain independently owned and updated while still being reachable through a common interface, which is the central benefit a distributed-object approach brings to this problem over a monolithic centralized design.

The Booking Client is the customer-facing UI (web or app) through which a user searches availability, books seats, or returns a ticket. The Booking Broker is a façade object that receives the client's request, determines which venue(s) it concerns, and forwards seat-availability queries or booking/return operations to the appropriate Theatre Proxy — a remote-object stand-in for one venue's own seat-inventory system, so that each theatre's internal seating data structure and box-office system stays local to that venue and is never replicated centrally. Booking a seat is executed as a request on the specific Theatre Proxy that owns that seat, so no cross-venue coordination is needed for an ordinary booking. Returned tickets are routed to a Resale Queue, which the Booking Broker also consults (alongside the owning Theatre Proxy) when servicing a last-minute availability query, so a returned seat becomes visible for resale without the owning venue's own system needing to distinguish "original sale" from "resale" inventory.