Distributed system

A distributed system contains communicating computing components whose coordination crosses machine boundaries. Distribution can improve capacity or fault tolerance, but it introduces communication and partial-failure problems. The physical placement of components does not by itself determine who controls them.

Fix the operation being considered and the conditions under which it must complete. A mandatory service dependency $u\to v$ means that completing the designated operation of $u$ requires $v$ to supply its designated service. Dependencies can be represented by a directed graph. The operation and conditions matter: an operation that can use an already retained result need not require a new response from its original source.

A directed path of mandatory dependencies propagates necessity. This follows by mathematical induction on the path length: one edge is the definition, and composing one further necessary condition gives the induction step. Consequently, if every replica requires the same component, losing that component can block the operation at every replica. Keeping copies of other components does not remove the shared requirement. Conversely, the availability of every dependency is not by itself a proof that an operation will complete.

In the client-server model, a network client requests a service supplied by a network server. It can be used within a federated deployment or a centralised one; it does not by itself determine whether an application respects the end-to-end principle.

A network server supplies a service to clients. Its role is logical rather than necessarily a single machine or location.

A network client initiates requests for a service. In an encrypted protocol it may be a cryptographic endpoint even though the service implementation has several further internal components.

Data portability permits moving useful application data between implementations or providers. An export format alone need not reproduce a provider's interfaces, credentials or service behaviour, so portability and service interoperability are distinct design questions.

Fault tolerance is the ability to continue satisfying a specified service property despite a stated class of component failures. The failure model and the property matter: preserving stored bytes, accepting new connections and finishing an operation are different requirements.

For an observation period of duration $T>0$, let $T_{\mathrm{up}}$ be the total time during which a service meets a specified condition. Its measured service availability is $A=T_{\mathrm{up}}/T$. The condition must say which operation can be performed: accepting a new user and serving an already admitted user can have different dependencies. A mandatory service dependency can reduce service availability even when all data copies remain intact.

A failure domain groups components that can be affected by a specified shared failure. The relevant grouping can follow physical infrastructure or an administrative dependency. Distinct sites do not establish independent behaviour when they still depend on the same component or decision. The grouping must therefore be stated relative to the failures under consideration, rather than inferred from distance alone.

Data replication maintains multiple copies of data. Its value for fault tolerance depends on failure independence, update behaviour and other service dependencies; several copies can still share one operator or a common point of failure.

Cloud computing offers remotely supplied computing resources and services through a service interface. It can make capacity easier to obtain while moving operational and state dependencies to a provider. A distributed physical implementation can remain centrally controlled.