Question 6 of 8: Distributed Software Systems

Question 6: 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.

Note: the answer to (c) below makes the security of the online purchase an explicit design concern, stated as an assumption. The printed paper letters this question's sub-parts (c)/(d)/(e), continuing the alphabet instead of restarting at (a); the page-1 marking scheme confirms exactly three sub-parts worth 5/5/10, so they are lettered (a)/(b)/(c) 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 Store E-Commerce System

Modelling each regional distribution centre's own product inventory as its own remote object (rather than one shared, centralized database of every unit of stock in the country) lets each warehouse's stock-management 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 Shopper Client is the customer-facing UI (web or app) through which a user browses the catalogue, checks availability, or places an order. The Order Broker is a façade object that authenticates the shopper (verifying their login session before accepting any purchase request), determines which regional distribution centre(s) the request concerns, and forwards stock-availability queries or purchase operations to the appropriate Warehouse Proxy — a remote-object stand-in for one distribution centre's own inventory-management system, so that each warehouse's internal stock database and fulfilment logic stays local to that facility and is never replicated centrally. Buying a product is executed as a request on the specific Warehouse Proxy that will actually fulfil the order, so no cross-warehouse coordination is needed for an ordinary purchase; the Order Broker calls the external Payment Gateway to charge the customer only once the chosen Warehouse Proxy has confirmed and reserved the stock, and rolls the reservation back if payment is declined. Because buying online sends login and payment data across the public Internet, security is designed in (an assumption stated below) and layered at the two points where sensitive data actually crosses a trust boundary rather than throughout every internal call: the Shopper Client ↔ Order Broker link is carried over an encrypted (TLS) channel and every purchase request is authenticated against the shopper's session before the broker will act on it, and the Order Broker never itself stores or forwards a raw card number to the Payment Gateway — it forwards a single-use payment token obtained directly by the client from the gateway, so a compromise of the Order Broker or any Warehouse Proxy cannot expose stored payment credentials it never held in the first place.