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.

A protocol for detecting that a distributed computation has completed. Merely observing each participant idle at different instants need not establish a simultaneous idle state; the protocol must account for intervening changes and communications.

Hard state persists until explicitly changed or deleted. The distinction from soft state concerns maintenance and recovery rules rather than simply whether the storage is volatile.

Soft state is maintained through refreshes and expires when they cease. Continuing participants can rebuild it through later communication, trading refresh overhead and temporary inconsistency for automatic cleanup and recovery.

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 supplies configurable computation resources through a computer network, drawing on a shared pool that users can obtain and release with little provider intervention. The NIST definition distinguishes five characteristics: on-demand self-service, broad network access, resource pooling, rapid elasticity, and measured service. Together these describe how capacity is requested, shared, scaled and accounted for.^[ref]

For example, a group running a numerical simulation can request several virtual machines, execute independent runs, save the results and release the virtual machines. Rapid elasticity concerns changing allocated capacity as demand changes; measured service records usage such as processor time or storage. A physically distributed system can have a single operator: physical distribution and administrative control answer different questions.

Measured service is the cloud-computing characteristic in which resource use is monitored, controlled and reported through metering appropriate to the service. Examples include processor-hours, stored bytes, network transfer and active accounts. Metering makes usage visible to the provider and consumer; it does not require one universal billing formula.^[ref]

For example, a batch of simulations can record the number of machine-hours consumed independently of the number of simulations completed. A failed run may still consume resources. Selecting a meaningful unit therefore requires distinguishing allocated capacity, elapsed use and delivered work. These measurements support accounting and capacity decisions without by themselves measuring the scientific value or correctness of the results.

Rapid elasticity is the ability to provision and release computing capacity quickly in response to demand, often automatically. The consumer may experience capacity as readily available even though the provider operates finite physical resources.^[ref]

For example, a service can add workers when its queue grows and remove them after the backlog clears. A control rule needs an observation signal, a scaling policy and time for new workers to become ready. Elastic capacity does not make every program parallel: a serial bottleneck, shared database or slow startup can prevent additional workers from increasing throughput. Releasing capacity also requires preserving needed state outside workers that may disappear.

Resource pooling combines provider computing resources to serve multiple consumers, with physical and virtual resources assigned and reassigned according to demand. NIST emphasizes multi-tenant service and some location independence: consumers generally select an abstraction or broad location requirement rather than one permanently assigned physical server.^[ref]

Pooling can improve utilization when consumers' peak demands occur at different times. It also requires isolation and allocation controls so that one consumer cannot read another's data or monopolize all capacity. For example, virtual machines may share a physical host while retaining separate address spaces. The resource pool and the mechanism enforcing its boundaries are distinct design responsibilities.

Multi-tenancy lets distinct consumers share a software service or computing infrastructure while retaining separate data and permitted operations. A tenant is the consumer or administrative grouping treated as one isolated customer. Resource pooling commonly assigns shared physical resources dynamically among tenants.^[ref]

For example, two laboratories can use one hosted database application. Each laboratory's users must access only their permitted records, even when both laboratories' records occupy the same database relation. Checks on each database query and limits on resource use serve different purposes: data isolation does not prevent one tenant's expensive work from delaying another. Separate virtual machines are one possible implementation boundary, rather than a requirement of multi-tenancy.

Broad network access means cloud capabilities are reachable over a network through standard mechanisms usable by different kinds of client platforms. NIST lists phones, tablets, laptops and workstations as examples.^[ref]

For example, a browser interface and an application programming interface can expose the same service to interactive users and automated analyses. Network accessibility does not imply public authorization: a private cloud can restrict authenticated clients while still using broadly supported network interfaces. Latency, bandwidth and intermittent connectivity affect how an application should divide work between client and service; an accessible remote operation is not equivalent to a local memory access.

On-demand self-service lets a consumer provision a computing capability when needed without requiring a human interaction with the provider for each request. The consumer might request server time or network storage through a portal or application programming interface.^[ref]

For example, an authorized research workflow can request a temporary machine, run an analysis and release it through automated calls. The provider can still enforce quotas, permitted configurations and account policy. Self-service describes how a request is fulfilled; it does not promise unlimited capacity or remove the need for authorization. Automating repeated provisioning makes temporary resources practical while leaving lifecycle and data-retention choices explicit.