The architecture of a distributed system describes its software components, their responsibilities and interfaces, how they interact, and where they run.
For a set of components and a set of computers , distinguish
A pair permits component to interact with component ; places component on computer . Logical organisation and physical placement are distinct: interacting components need not occupy different computers, and one component may have instances on several computers.
Architectural Styles
These styles describe how components are organised and communicate. A system may combine several styles.
A layered architecture organises components into ordered layers . Each layer provides services to higher layers through a defined interface and uses lower-layer services to implement them.
Requests descend through the layers needed to perform an operation; responses return upwards. Each layer can process a request or response rather than merely forwarding it.
Strict Layering
A layer uses only the immediately lower layer: may call , but does not bypass it to call deeper layers.
Relaxed Layering
A layer may use any lower layer, allowing some intermediate layers to be bypassed.
An object-based architecture organises components as objects that encapsulate state and behaviour and interact through method calls on defined interfaces.
For objects , a call dependency means that may invoke a method exposed by . The calling object uses the receiver’s operations rather than directly manipulating its internal state.
Each arrow points from caller to receiver. Paired arrows represent calls in both directions, not the request and response of one call.
An event-based architecture organises components around publishing events and reacting to events delivered through an event bus, rather than directly invoking a particular recipient. An event is a message describing an occurrence and may carry associated data.
Components subscribe to events of interest. Let be true when ‘s subscription matches event . The intended recipients are
The bus routes events according to these subscriptions; the publisher need not identify the recipients. A component may both publish and receive events.
Selected publications and deliveries are shown. A and B subscribe to ; B also publishes . Its downward arrow is a separate publication, not a response to .
A shared data-space architecture organises communication around a shared, persistent collection of data. Components publish records into this space and obtain data through queries, retrieval or registered interests, rather than addressing the components that produced it.
If a published record remains in the shared space , so that , another component can access it later even when the producer is no longer active. Persistence decouples production and consumption in time; retention, updates and removal follow the data space’s rules.
Selected records and operations are shown. A and B obtain stored record ; B also publishes . The records remain available according to the space’s retention rules, independently of these deliveries.
Centralisation concerns where service provision or coordination is concentrated, rather than how components communicate. A centralised system can use the architectural styles above.
A centralised architecture concentrates service provision or coordination at a central point on which participating clients depend. Clients submit requests to a server, which performs the required operations and returns results.
In a synchronous request–reply interaction, the client waits for the result before continuing the dependent computation. The server receives the request, provides the service, and sends a reply.
Solid segments show computation in this interaction. The client waits during request transmission, server processing and reply transmission; server-side queueing is omitted from the diagram.